Security Features in Oracle Autonomous Database

Security is a primary concern for enterprise customers and one of the most discussed topics when it comes to move to the cloud. The same questions are being raised again and again:

  • Is the cloud secure?
  • Is my data safe their?
  • Does it meet my compliance requirements?

Before starting with the technical security features that addresses these questions, let’s take a step back and see what this is all about.

Obviously it is all about DATA, first of all the sensitive one, as they are organization’s most valuable asset in today’s world and hackers spare no effort to have access to them. Following are examples of data breaches where data was not very well protected and hundreds of millions of records where stolen by attacking a database:

Organization‘s most critical data are not stored in flat files (I hope at least), but in databases, and hackers attempt to attack them from many different perspectives. They have time, invest a lot of effort, and are inventive. They can steal an end user’s password, exploit weaknesses in database applications, attack the network, get access to raw data files, and try to get access to data copies, which might not be as well protected as production systems.

Common reasons for database breaches are unencrypted data, not applied security patches, administrator snooping, malware or viruses, and poor network isolation.

To protect our database, it is time for the security features of Oracle Autonomous Database on Shared Exadata Infrastructure:

No alt text provided for this image

Network Security Groups, API Audit Logs, and VCN Flow Logs are security features for supported OCI resources and not specific and limited to Autonomous Database.

Encryption

1. Transparent Data Encryption (TDE)

TDE enables you to encrypt data on storage media. After the data is encrypted, this data is transparently decrypted for authorized users or applications when they access this data. In Oracle Autonomous Database TDE is enabled by default and can NOT be disabled. Encryption keys are managed automatically by Oracle.

No alt text provided for this image

In the event that the storage media or data files are stolen, it is not possible to read the data:

No alt text provided for this image

2. Backup Encryption

Backups are taken automatically. All Backups are encrypted and this configuration can NOT be changed:

No alt text provided for this image

3. SQL*Net Encryption

All connections MUST use TCP/IP + SSL (TCPS). The server-side configuration can NOT be changed. If you try to disable SSL on the client-side, you would not be able to establish a connection anymore:

No alt text provided for this image

To establish a connection, the Client Credentials (Wallet) is needed, which can be downloaded after Autonomous Database creation. It is the customer‘s responsibility to store the wallet files in a secure location and share them only with authorized users. Wallets can be rotated in case they fall in wrong hands or due to regulatory compliance.

Network Access Control

4. Access Control List (ACL)

You can control and restrict access to your Autonomous Database by setting network Access Control Lists (ACLs). By default no ACL is specified and the database is accessible from any IP address (wallet, username, and password required). Addresses can be specified in the form of individual IPs or CIDR blocks. There is no downtime when implementing ACLs.

No alt text provided for this image

After listing your trusted IPs, all connections from everywhere else will be rejected.

No alt text provided for this image

4. Private Endpoints

With Private Endpoints you can keep all traffic to and from your Autonomous Database off of the public internet. The only access path to the database is through your Virtual Cloud Network (VCN) in your OCI. Here is a step by step implementation of Private Endpoints.

No alt text provided for this image

While database creation, you have the choice between configuring public or private access:

No alt text provided for this image

6. Network Security Groups (NSGs)

You can use NSGs to restrict access to Autonomous Database with Private Endpoints by specifying the according ingress and egress rules in the NSG. If you want to restrict the access to only one specific IP address, enter the IP as a /32 CIDR block, e.g. 10.0.2.2/32.

No alt text provided for this image

System & Data Protection

7. Database Vault

Stolen privileged user credentials are one of the most common attack vectors used by hackers. Database Vault restricts access to application data by privileged users, reducing the risk of insider and outside threats and addressing common compliance with data privacy laws and standards such as the EU General Data Protection Regulation (GDPR).

No alt text provided for this image

8. High Privileges Restrictions

In Autonomous Database, no access to operating system or logon with SYSDBA privileges are possible to prevent installing or modifying any software on the system.

No alt text provided for this image

9. SQL Command Restrictions

To ensure the security of Autonomous Database and eliminate human error, some SQL commands are restricted. For example, it is not possible to turn off encryption, set the failed logins count to unlimited, or to drop a tablespace:

No alt text provided for this image

Even as ADMIN user, it is not possible to reduce the always-on security enabled by default.

Sensitive Data Discovery & Masking

10. Data Redaction

Oracle Data Redaction enables you to mask (redact) data that is returned from queries issued by applications at runtime. Data itself is not changed! Common use cases are redaction of credit card numbers, personal IDs, and birth dates to comply with industry regulations such as Payment Card Industry Data Security Standard (PCI DSS) and the Sarbanes-Oxley Act. Policies for data redaction can be implemented by the customer using DBMS_REDACT PL/SQL Package.

No alt text provided for this image

11. Oracle Label Security (OLS)

OLS implements multilevel access controls based on the classification of the data and the access label of the application user. You can label your data using different sensitivity levels and allow users to access only those data records with the correspondent level. An example is to restrict access to data by region:

No alt text provided for this image

12. Data Safe

Data Safe is a unified control center for your Oracle Databases which helps you understand the sensitivity of your data, evaluate risks to data, mask sensitive data, implement and monitor security controls, assess user security, monitor user activity, and address data security compliance requirements. A common use case for data masking is to mask your test and development databases after being created as a clone from production databases containing sensitive data:

No alt text provided for this image

Auditing

13. Database Auditing

Database Auditing enables selective and effective auditing inside the Oracle database using policies and conditions. Predefined policies are activated by default to monitor any abnormal activity. Additional audit policies can be configured to audit based on specific IP addresses, programs, time periods, or connection types. It is enabled by default and can NOT be disabled.

No alt text provided for this image

14. API Audit Logs

Users can stop, start, create and delete an Autonomous Database by using the Cloud Console or REST API calls. All of these are audited by the Audit Service.

No alt text provided for this image

15. VCN Flow Logs

With VCN Flow Logs you can view connection information for traffic within your VCN and keep detailed records of every flow that passes through your VCN and presents this data for analysis, including source and destination of the traffic, quantity of traffic, and permit or deny action taken. This information can be used for network monitoring, troubleshooting, and compliance.

VCN Flow Logs comes into play when we use Private Endpoints in Autonomous Database as described in point number 4.

SELF-PATCHING

16. The best is yet to come: Self-Patching

According to the Verizon 2018 Data Breach Investigation Report, 85% of security breaches occurred after the CVE was published. But why are security patches not applied in time if we know how critical they are? The answer is simple, because patching manually operated databases is usually a big challenge for many organizations due to downtime restrictions of applications running 24/7 and time and human resources required.

In Oracle Autonomous Database security patches are automatically applied every quarter. Patching can also occur off-cycle if a zero-day exploit is discovered narrowing an unnecessary window of vulnerability.

In addition, patches are applying in a rolling fashion across the RAC cluster nodes without any downtime for applications using Transparent Application Continuity.

No alt text provided for this image

Before we come to the end of this long blog post, here is an overview of current Oracle Cloud Infrastructure compliance programs that span across various industries:

No alt text provided for this image

And ALWAYS keep in mind, security is a SHARED responsibility!!!

No alt text provided for this image

Stay healthy, have fun and success, and keep your data safe!

Would you like to get notified when the next post is published?