Autonomous Database Security Central

April 27, 2023 | 13 minute read
Kris Bhanushali
Sr. Principal Product Manager
Text Size 100%:

Autonomous Database Security Central

This blog page is maintained by the Product Management team for Oracle's Autonomous Database on Dedicated Exadata Infrastructure. We are hoping this can help customers and prospects find all security aspects of the service in one place, by release timeline. We would appreciate your comments on improvements we can bring to make the service even more resilient and meet your corporate security requirements.

 

Let me take a moment to introduce you to the Autonomous Database and how security works so you have some context on why we do things the way we do and the advantages. 

Autonomous Database ( henceforth I will occasionally refer to it as ADB, and since we are talking about ADB on dedicated Exadata infrastructure, how about ADB-D? ) is a fully managed database service that runs on the Exadata platform. It starts at Oracle database 19c and subsequent release updates and versions are available in the service based on DB support and RU schedules.

Here's what ADB-D promises to provide customers, 

  • Automation to easily deploy databases from simple, single instance dev/test to multi-region DR setup via console UI, APIs, SDKs and Terraform.
  • Pre-configured, optimized deployments for Data Warehouses, Oracle Applications or customer home-grown applications with dense consolidation.
  • Service up-time SLAs that can meet tier 1 application uptime requirements. For eg, deployments with a regional Data Guard standby get a 99.995% uptime SLA.
  • Automated patching of all types - security patches for Infra, GI, OS, Container Databases, and all feature release updates (RUs) i.e., everything including one-off's specific to a customer's deployment. You pick a schedule, the automation runs the update and, in most scenarios, without any downtime (remember, we have to meet that SLA?) 
  • Automated backup/recovery/Cloning - Automatic Daily/Weekly backups both on the primary and standby sites with PITR at the click of a button.
  • There is also the Autonomous Database (ADB) level isolation for security and performance, so you don't get noisy neighbors when you are consolidating multiple applications in a single Autonomous Container Database (ACD).

Now clearly, to deliver this level of automation, performance, and security isolation, certain aspects of the configuration need to be locked down.  The service automation deploys your database / Virtual Machine in a gold configuration with all binaries digitally signed to prevent any tampering and once deployed, this configuration is not accessible to customers to alter in any form. Any changes / updates go through the automation workflow as a validated build.

From a security point of view this is advantageous and avoids database machine and Oracle home configuration drifts. The downside is you cannot bring your own tools, scripts etc. to the machine (down /upside depending on how you look at it)

The service provides all the monitoring and security functions needed to run any Tier 1, enterprise database application and makes many of the external, third-party tooling redundant, reducing clutter and simplifying the experience. 

Hopefully, the explanation above sets some context on the ambitions of the Autonomous service to simplify database management and bring a paradigm shift in how customers manage their Oracle Database fleets going forward. 

In case you want to dive deep into what Autonomous Dedicated offers, here's a series of Blogs by Robert Greene on various aspects of the service.

Also, here is a direct link to all Autonomous on Dedicated workshops on Oracle LiveLabs and there is an entire line-up of step-by-step guides in the security section as shown below

Security Workshop on Oracle LiveLabs

Now, since this is a security blog, let's take a look at all the security functions available in the service. I will arrange it chronologically with the latest released features appearing on the top. This blog will be updated with each new release (GA) of a security feature.


 May 10, 2023

An advantage of autonomous is the speed at which the service can fix security vulnerabilities across the fleet. As an enhancement, we now release support for monthly updates to any Infrastructure security vulnerabilities with a CVSS score of 7 or higher. In addition, any other security updates would be part of the quarterly Release Update (RU)

The monthly security updates would be online using ksplice,  without the need to roll nodes in the cluster i.e. the updates are expected to be tranparent to the application with no downtime involved.

The New Feature announcement page in the OCI documentation set reflects this change in May and is a good page to bookmark to keep up to date on releases.

Additional details on service maintenance including monthly Infrastructure patching are documented here

April 25, 2023

These are the security features currently available in ADB on Dedicated Exadata Infrastructure. Sometimes we stagger the release of a feature in public cloud regions v/s Cloud@Customer and if that’s the case I will point it out. So, unless otherwise mentioned, the feature set can be expected to be available in both deployment platforms.

 

Bring Your Own Certificate  ( ADB-ExaCC only)

We recently GA'd this feature for Cloud at Customer deployments. Customers can now bring their own CA signed certificates to the Autonomous VM Clusters. The service allows you to rotate certificates before expiry and provides notifications 6 weeks before expiry. Needless to say, a trusted CA signed certificate provides additional assurance to client applications that they are talking to the intended database host and further enhances security from MITM attacks. The service supports both mutual TLS ( client needs a connection wallet) and one-way TLS, where clients can connect without the need for a wallet. The latter helps support legacy apps that may not be so easy to modify to support wallets.

There is a step-by-step guide to seed your own certificate in an Autonomous VM Cluster in the Oracle LiveLabs Security Workshop.

 

 

Password-less database user connections using Kerberos tokens

We support Kerberos with CMU to configure your ABD-D instances to authenticate database users with Kerberos tokens instead of a username/password. Customers who use Kerberos on-premises can bring a similar configuration to their ADB-D instance in OCI.

Documentation on using ADB-D with Kerberos, CMU and MS-Active Directory is linked here

 

Pick your own SCAN listener port

Instead of the default 1524 for non-TLS and 2484 for TLS, customers can now choose their own port # from a wide range. Some port ranges a blocked since they are used internally but you can pick one of thousands of available ports. 

On the Autonomous VMCluster console page, you find the option in the Advanced tab section, so this does not get in your way if you stick to defaults and continue to provision the VM Cluster with minimum inputs. Also note that you cannot change the assigned port once your VM is provisioned, so pick carefully. We have not come across anyone asking for the ability to change ports once provisioned but if you are one of them, let us know in comments.

This LiveLabs guide has details on where to find this in the UI and here's the documentation page in the Autonomous VM Cluster provisioning section.

 

TLS or mTLS, that is the question

In the advanced section of the Autonomous VM Cluster provisioning page, you also get to pick if you want to connect to the database over mutual TLS or one-way TLS. mTLS is a fancy name for when the client needs to present its certificate as well such that the database server will only respond to trusted clients. Not very common, and sometimes cumbersome but certainly more secure than letting any client with a user/pass connect to a database. Of course, clients then need to present a wallet that holds the client-side certificate and the servers root certificate. These certificates also need to be rotated upon expiry. One-way TLS offers the simplicity of a wallet-less client, which some legacy application may find convenient.

 

Operator Access Contol (OpCtl)

While automation is at the heart of most of the Autonomous operations, including detection and diagnostics collection, occasionally, human operators have to intervene to resolve an incident and need to log into an Autonomous VM Cluster. This is something that in common across cloud providers, especially PaaS and SaaS since the provider has more responsibility than merely providing a virtual infrastructure. 

With ADB-D, we allow customers to approve and control when and how an Oracle operator can access their VM Cluster for any maintenance operation or incident management. Once a customer brings their Autonomous VM under OpCtl, there are no more named user accounts on the VM. Operators are required to open an access request and credentials are generated dynamically in response to a customer's approval of such request. Operator specifies the reason for access in the request and in most cases provides the corresponding ticket he/she is working on.

Operator Access Control workflow

Once logged in, every action of the operator is logged and sent to customer in real-time, pushed either to their SIEM directly or the OCI Logging service based on customers preference. That way, customer is completely aware of operator’s actions and can even terminate operator's session if they so desire. 

In addition, the level of access available to an Operator is on an as-needed basis, in line with the task they need to perform. 

The Operator Access Control doc set has all the details, down to the command and filesystems each access level provides.

Here's a tech brief on the subject as well.

My colleague Jeff Wright has published this video tutorial outlining the product with a neat demo and here's a short blog as well.

 

Database Vault comes built in

While OpCtl is great for Privileged Access Management (PAM) for Oracle Ops, customers may choose to use another PAM tool that has been available as a database option for over a decade now - Database Vault. 

ADB-D has Database Vault pre-configured and ready to use. Customers can create their own realms and drop schemas into it to protect data from their own privileged users aka, admins. 

Since there is nothing to install or setup, I am pointing you straight to the user section of the doc

 

Support for AzureAD Directory Service (ADB-D in Public Cloud Regions only)

We released support for an on-premises MS Active Directory integration with Autonomous from Day 1. We have also enabled the service to integrate with AzureAD in any of the Azure regions. 

Azure AD integration with Autonomous Database

A database user or client application with an identity in AzureAD can now login to their Autonomous Database using AzureAD access tokens. Users need the database instance registered as an application in AzureAD. Mapping of database global users to AD groups is fully supported as well.

Implementation details can be found in doc here

Database Security PM has published this feature announcement blog  that has additional resource links

 

Integration with OCI Identity and Access Management service

Besides on-premises Active Directory and Azure AD, you also have the option to use OCI's native IAM service to manage your database users  i.e. map your database global users straight into groups setup in OCI IAM. Btw, OCI IAM in-turn allows you to federate identity with your on-premises directory so this still allows you to continue managing user identity the same way as you do on-premises

An introductory blog on integrating ADB-D with OCI IAM is written here by my colleague and Database Security PM, Alan Williams

 

Digitally Signed Binaries

All code deployment in the ADB-D service is through a change management workflow, hashed, encrypted and cryptographically signed to ensure deployment is tamper-proof. This greatly reduces the risk of an insider injection attack and makes autonomous deployments more secure than most on-premises systems.

 

Automated data masking, centralized user auditing, compliance scans and more

ADB-D integrates with OCI Data Safe service, a data security service across all of our database services in OCI. With Data Safe you can, 

1. Discover, subset, and mask autonomous database with a variety of masking formats, using the typical cloud automation stack - API, Terraform, SDK etc

2. Conduct routine security assessments across your autonomous database estate and generate compliance reports

3. Move audit data into Data Safe to centralize and provide separation of duty between database admin and security admin

Data Safe comes free with autonomous for up to 1M audit records per month which should meet most database needs without additional spend

Data Safe doc is here

Data Safe has some neat alerting capabilities as well, outlined in this blog...and this FAQ may help as well

 

Database Level Access Control Lists (ACLs)

In addition to all the network security, subnet rules, NSGs etc., there is one other neat access control feature you may love in Autonomous. ACLs at the ADB level. The service lets you define an allow-list of IP addresses that can access the database. This feature is pretty cool in the sense it can block non-approved users / applications from accessing the database even if they have a valid user/pass. For e.g., you can block ad-hoc querying on production and ensure only connections coming from valid application server IPs can go through.

Access Control Lists for Autonomous Database

More on setting up ACLs on Autonomous Dedicated instance here

 

Encryption Key Management 

All data at rest and in transit is encrypted using Oracle's Transparent Data Encryption (TDE) and utilizing AES 256 encryption algorithm (duh!) TDE master encryption keys can be stored on the host VM Cluster or moved off to either the OCI Vault Service or to your on-premises Oracle Key Vault depending on whether its Autonomous in public cloud regions or on Exadata Cloud@Customer, respectively.

There is complete automation to associate and rotate master keys. Also, key management is mostly at the Autonomous Container Database (ACD) level so that the ADB user experience remains simple - they need not worry about how keys are being managed. The fleet admins / security admins governing the entire database fleet can set it up once.

Oh, and did I mention that OCI Vault service hosts keys on FIP140 Level 3 compliant HSM devices?

More on encryption and key management documented here

Here's a blog since we first announced support for externally managed keys

 

The OCI Compartment Isolation Model

At the service level, Autonomous VM Clusters, Container Database and the Autonomous Databases can be separated into different OCI compartments with IAM privileges determining the level of access users have to these resources. This can serve as a way to isolate resources between Application teams, separating DB Admins from Security Admins, Developers etc and providing access and visibility as-needed.

It’s important to think through and come up with a sound compartment level strategy that works for your organization. Too much isolation can be a maintenance headache, too little may give users unnecessary privileges, so find the right balance.

 

Network and Infrastructure Isolation

Autonomous on Dedicated Exadata Infrastructure runs on ...well, virtual machine clusters dedicated to a single customer tenant, and therefore these machines can be in your own private virtual network or VLAN (depending on deployment) This is often times a requirement for security conscious customers who desire network / physical infrastructure level isolation for their enterprise data.

ADB-D allows you to isolate your workload in various ways. Here's some isolation models I have seen customers adopt for better security and governance,

  • Separate VM Cluster for each line of business. This, along with compartment quotas also helps with managing cloud spend.
  • Separate Autonomous Container Databases for Dev/Test and Prod. This one seems like a no-brainer, especially since Data Guard failover is at the ACD level, you seldom want to mix dev/test/prod in the same container. 
  • Rare, but occasionally some customers like to put an entire LoB or a critical application on its own separate infrastructure

Whatever your preference is, the point is, Autonomous on Dedicated Infrastructure gives you the most secure and isolated configuration to the densest ( is that a word?) possible consolidation and everything in between.

 

Separation of Duties

Another often overlooked security paradigm is how a service architecture enables a customer to provide better internal governance. With ADB-D we strive to help customers organize themselves to govern large fleets of autonomous databases to keep security and TCO in check, while at the same time provide agility to their own internal engineering and business units to keep innovating at a faster pace. 

As such, a proposed organizational model to run your autonomous database fleet is to have a central Fleet Administrator(s) who's responsibilities include,

  • Defining SLAs and provisioning Autonomous Container Database in line with application SLAs
  • Ensuring the service is setup in line with corporate security & availability standards. For e.g., keys managed externally v/s on-host, ACDs deployed with standby across region v/s AD
  • Defining the compartment model and keeping costs under control via architectural reviews - e.g. Is the application using autoscaling effectively? this can have a huge impact on sizing and on-going costs

The database developer / DBA on the other hand may be responsible for, 

  • Deploying autonomous databases as needed
  • Building dev/test pipelines with automated provisioning, testing, decommissioning via CI/CD pipelines
  • Cloning / Masking dev/test instances
  • Setting up autoscaling / fine tuning CPU and monitoring usage
  • And of course, building applications on Apex, ORDS or other language-based apps

Separation of duty

 

 

The idea is that a central group with governance responsibility ensures smooth running of the fleet, cost control and compliance, while the larger org of "consumers" focus on building applications / being productive without process speedbumps. Now, is that what they call a win-win? :-)

 

 

Kris Bhanushali

Sr. Principal Product Manager

Kris Bhanushali is a Senior Principal Product Manager for Oracle's Database Cloud Service. If you have any questions about this blog's content, please email him at kris.bhanushali@oracle.com


Previous Post

Second Quarterly Update on Oracle Graph (2023)

Rahul Tasker | 6 min read

Next Post


Latest Autonomous Data Warehouse innovations breaking through data management boundaries

George Lumpkin | 8 min read