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.
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.
Couldn’t be simpler but let’s walk through the process…
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:
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.
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: https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
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.
Let’s assume my client IP address for my desktop workstation is 220.127.116.11 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 18.104.22.168 in the form:
Everything is now set so all that’s left is the last step….
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.
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.
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.
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.
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.
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:
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 Oracle.com.