Skip to Main Content
  • Questions
  • Oracle has any feature similar to "Always Encrypted" that is offered by SQL server?

Breadcrumb

Dev Live Dev Intro

We are celebrating Developers at AskTOM. We welcome Developers of all levels of experience to join us at our FREE Developer Live events coming in August and September. Just click on the left to register today! If you are brand new to Database Technology, then we also have got you covered. Just click on the right for your comprehensive FREE training program to kick start your Oracle Database Development journey!

Question and Answer

Chris Saxon

Thanks for the question, A.

Asked: August 11, 2020 - 6:04 am UTC

Answered by: Chris Saxon - Last updated: August 11, 2020 - 6:05 pm UTC

Category: Database Administration - Version: 12.1.0.2

Viewed 100+ times

You Asked

Hello,

It would be great if you can help me here.

Can you please share if Oracle has any feature similar to the "Always Encrypted" feature offered by SQL server? Link pasted at end has information on "Always Encrypted".

I understand that Oracle offers data redaction to mask data. However, my understanding is that users with high authorization can bypass it. Oracle also offers Vault to control data access. However, there still will be Oracle users that can see the data in clear.

It would be really helpful if you can share some pointers.

Thanks,
AB
-------------------------------------------------------------------------------------------------------------------------------
Link:

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-database-engine?view=sql-server-ver15

Text from this link:

Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to the Database Engine (SQL Database or SQL Server). As a result, Always Encrypted provides a separation between those who own the data and can view it, and those who manage the data but should have no access. By ensuring on-premises database administrators, cloud database operators, or other high-privileged unauthorized users, can't access the encrypted data, Always Encrypted enables customers to confidently store sensitive data outside of their direct control. This allows organizations to store their data in Azure, and enable delegation of on-premises database administration to third parties, or to reduce security clearance requirements for their own DBA staff.


and we said...

Oracle Database has many options to help you encrypt and control access to data. I'm not familiar enough with Always Encrypted to know exactly how these match up, a couple of the key features to look into are:

Transparent Data Encryption

Automatically encrypt data at rest. This stops people opening data files and viewing their contents outside the database. You can do this at the tablespace or column level.

https://www.oracle.com/a/tech/docs/dbsec/aso/advanced-security-wp-19c.pdf

Database Vault

Define policies to control who can see what so you can control access and enforce separation of duties

https://www.oracle.com/a/tech/docs/dbsec/dbv/dv-ds-19c.pdf

You can find out about other security features at:

https://www.oracle.com/database/technologies/security.html

and you rated our response

  (3 ratings)

Reviews

August 11, 2020 - 2:43 pm UTC

Reviewer: A reader

Thank you for replying Chris.

Basic idea of "Always Encrypted" is that the data is always encrypted when it is on SQL server. Encryption and decryption occurs via the client driver. Only client application can encrypt and decrypt the data.

We evaluated TDE but it only deals with the data at rest, example stolen hard disk.

We also considered Database Vault. It provides protection against unauthorized access. However, the data will still be in the clear format in the DB and there can user accounts that access the data.
Chris Saxon

Followup  

August 11, 2020 - 6:05 pm UTC

See the comments from Rich Evans - DB Security PM - below.

Oracle has any feature similar to "Always Encrypted" that is offered by SQL server?

August 11, 2020 - 3:43 pm UTC

Reviewer: Amin Ezzy from NJ USA

Hello,

Oracle has its network security configuration to encrypt database between server and application.
May be this link can answer more
https://docs.oracle.com/cd/E11882_01/network.112/e40393/asoconfg.htm#ASOAG9587

TDE is disk base datafile encryption. Decryption requires an encryption key that is password protected.

In case of Oracle DBaS, it is based on Oracle Exadata that uses ASM, which could be distributed among at least 14 Servers*12Disks. So chances to get that required disk and stealing it from Oracle Data Center (if that is possible), you still may not be able Mohave the required data. Again if the Encryption Key and the Password is stolen too.
Furthermore if ASM encryption is being used then chanced goes very low to get the required data. I think DBaS in Oracle cloud would be using more Exadata Full racks in a single cluster. That brings things very difficult to know which data is belongs to whom in case a disk can be stolen. A Stolen disk here might needs up to two encryption keys and thire passwords. We can go for ages actually if DBaS is discussed here.

If IaaS is being used then it is TDE on data files (Tabelspace or Colman), the VM will have an encryption key that could be password. If customer has the Password for the key then he is safe from the cloud provider and admin.

Further more, few words came in the questions. Each one is a db pack in Oracle.

Database Reduction, is to mask data between server and client, client can not decrypt the data. Used to protect SSN, Credit Cards.

Database Vault used to specify HOW, WHO, WHERE, and WHEN data can be accessed. By default DBA can not have data owner. Unless data owner give such access. It can also audit/report such activity beside ALLOW/DISALLOW/DIVERSE the required Action.

Chris Saxon

Followup  

August 11, 2020 - 6:05 pm UTC

Thanks for sharing

A defense-in-depth architecture within the DB

August 11, 2020 - 5:54 pm UTC

Reviewer: Richard C. Evans from San Antonio, TX USA

Hi AB,

SQL Server "Always Encrypted" does look like a very cool product but we do not have an exact feature to match it. Instead, we have multiple products or features that can help with this scenario that have been available as far back as Oracle 8i. As you've mentioned, there is TDE for tablespace or column encryption which transparently decrypts the data for the requesting SQL query. That solves the "side channel" attack and protects your data at rest, in RMAN backups, and in Data Pump Exports. The advantage of TDE is with tablespace encryption, so everything gets encrypted and you don't have to retrofit it, object-by-object, table-by-table, column-by-column, in the future. Again, it doesn't quite fit what you're looking for with "Always Encrypted" but let's keep going..

Another option that was mentioned was Oracle Database Vault (DV). We would recommend Database Vault to separate users who do not need to access sensitive data. This has the benefit of protecting privileges or roles, like preventing a user from using the CONNECT role to login from a non-approved host, IP address, or client program/module. Another advantage is being able to protect the application data from the application account - for example, developer's shouldn't login with the application credentials and if they do they won't be able to query the data. Again, with DV, you don't have to perform this type of protection on an object-by-object, table-by-table, or column-by-column basis. Database Vault is built-in to the kernel of the database so it travels with your database to other environments (containers, non-production, Data Guard standby DBs, etc.) and protects the data during an RMAN backup/restore operation. It doesn't do exactly what you're looking but I think it provides much more long-term, strategic, value than a column-level, client-side, encryption technique does.

We have other solutions that can 'mask' or 'redact' the column value itself, such as Data Redaction, Virtual Private Database (VPD), Label Security (OLS), and Real Application Security (RAS). With these you are in the driver's seat - you can keep them simple or make them as robust as you need. Do you want to make decisions to show the data based on LDAP groups or roles? You can do that too. Do you want to make decisions based on client program, client module, client IP, time of day, day of week, or just about anything else the database can learn about the client? You can do that too.

We believe that by keeping these security policies in the database we can centralize the controls and ensure that performance does not degrade due to large client-side encrypt and decrypt operations or the fact that the RDBMS optimizer doesn't know enough about the data to make parsing, pruning, compressing, or indexing decisions. Oracle's RDBMS kernel-based controls also have the advantage of not changing anything on the client or application levels, ensuring, no matter which application or client connects, they can all take advantage of the same security products. There are no certificates to deploy, manage or expire. There are no additional drivers to deploy.

If these controls aren't sufficient and you still need to do some level of Application encryption, there are third-party products which can offer something similar, for every major RDBMS, but please be careful about the application or client-side modifications required and the potential performance impact from the RDBMS not having any useful "insight" into the type of data, distribution of data, not being able to compress/deduplicate/index the data, etc.

If you'd like to discuss further, or learn more about Oracle's Database Security offerings, we have monthly "Office Hours" with Oracle Database Security Product Managers. They are held live on the second Thursday of the month and available as recordings in case you missed it or want to see previous events. You can sign up on AskTom's Office Hours section or by going to this URL: https://asktom.oracle.com/pls/apex/asktom.search?oh=3661

Regards,
Rich


Chris Saxon

Followup  

August 11, 2020 - 6:05 pm UTC

Thanks for clarifying Rich