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.

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.

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