Network ACLs for Autonomous Database Restrict Access

April 26, 2019 | 6 minute read
Keith Laker
Senior Principal Product Manager
Text Size 100%:

When you create an autonomous database instance it is created so that the database is accessible by all your database tools and applications via any IP address. In networking terminology: there is no whitelist or network access control list specified.

With the latest release, you now have a  simple way to add an additional layer of security around your Autonomous Database instances using network access control lists (ACLs for short). This provides a way to specify a list of client IP addresses that are allowed to connect to an Autonomous Database instance and all other IP addresses should be blocked. 

How to restrict access to your autonomous database in 5 steps!

Controlling client tools and application access to your autonomous database could not be simpler. In following the next 5 steps you will add an additional layer of network access.

  1. Goto the management console for your instance
  2. Select “Access Control List” under the “Actions” menu 
  3. Select the type of list being created -  IP or CIDR.
  4. Enter the list of values for the IPs or the CIDRs.
  5. Click Update.

Couldn’t be simpler but let’s walk through the process…

Step 1 - Accessing the management console

First stage involves signing into your cloud account using your tenancy name and cloud account. Then you can navigate to either your “Autonomous Data Warehouse” or “Autonomous Transaction Processing” landing pad as shown below:



Let’s now configure the network ACLs for the autonomous database instance “ADB-20180724-1655”. If we click on the blue text in the first column this will take us to the instance console page as shown below:




Step 2 - Selecting “Access Control Lists” from Action menu

Now click on the “Actions” button in the row of menu buttons as shown below:

As you can see, the Autonomous Database Action Menu continues to add functionality.  Recently we added the ability to update your license type.  For more information on the feature, take a look at the blog post here.

Step 3 - Select the type of list being created -  IP or CIDR.

A pop-up form allows you to enter the list or range of IP addresses that will be allowed to connect to your autonomous database:


Essentially you have two options at this point…you can either provide a comma separated list of IP addresses or you can provide CIDR blocks.  For more information on CIDR blocks, check out this definition on wikipedia:



You can mix-and-match the definitions of IP addresses and CIDR blocks by simply clicking on the “Additional Entry” button and making the appropriate selections…


If you need to remove an entry then there is an “x” icon to the right of each entry which will allow you to remove a specific line/entry. 

Step 4 - Enter the list of values for the IP or the CIDR.

Let’s assume my client IP address for my desktop workstation is and this is the only IP address that should be able to connect to my autonomous database. All I need to do is add an entry for the IP address in the form:


Everything is now set so all that’s left is the last step….

Step 5 - Click Update

Click the blue update button in the bottom left corner of the form and the changes will be applied. Notice that in all the above screenshots, the current state is “Available”. When you click “Update” the status will change to “Updating" until the network ACL is set.

All Done!

The database is still up and accessible, there is no downtime. When the update is complete the status will return to “Available” and the network ACLs from the access control list will take affect. 


Where is the ACL information stored?

All the information relating to the list(s) of network ACLs is stored directly in the database and treated like any other metadata. This means that your network ACLs are backed up automatically as part of the automatic Autonomous Database backup process. One thing to note is the following: If you need to restore the database to a previous point in time before you updated the ACLs,  then the network ACLs will be reverted back to the list as of that point in time. So after a restore it's  a good idea to check your ACLs are correctly set. 

What about access to the service console?

The service console is not be subject to network ACLs. This means that the service console can be accessed from different locations.   More importantly,  the management console itself does not expose any of your data, the use of network ACLs within is not really necessarily.

What about access to OML SQL Notebooks?

Oracle Machine Learning notebooks are also subject to ACLs. Therefore, if you try to login to OML as a user and your IP address is not whitelisted then you will get an "invalid connection" type error message. The admin user can always access the "Manage OML Users" console screen since the same rules apply as per the service console - managing OML users does not expose any of your data - which means that network ACLs are not enforced for this particular part of the management console.

What happens when you clone a database?

When you clone an Autonomous Database instance (the steps for doing that are outlined here) then your network ACLs are copied to the new clone. This means your clone will have exactly the same list of approved IP addresses. One less thing to worry about as a DBA! 



Wrapping this all up…this post has explained how, in 5 easy steps,  how you can restrict access to your Autonomous Database by creating a preset list of IP addresses (and/or CIDR blocks). You can view the complete set of steps below in the animated video. 

There is more information available in the documentation: 

  • Autonomous Data Warehouse doc is here
  • Autonomous Transaction  Processing doc is here 

An animation of the complete end-to-end process is shown here:

For more information on new features added to the Autonomous Database, take a look at to our “New Features” page on

Keith Laker

Senior Principal Product Manager

Product Manager for Autonomous Database and Analytic SQL with extensive experience in data warehouse and business intelligence projects. Worked in various roles, including post-sales consultancy, customer support, and product management at locations across Europe and US.


Previous Post

Oracle Database 19c Now Available on Linux

William Hardie | 1 min read

Next Post

Oracle Database 19c available on GitHub

William Hardie | 1 min read