Welcome to Oracle University's Oracle Cloud Infrastructure course on Oracle Autonomous Database. We're going to talk about setting up access control lists and private endpoints. My name's Kay Malcolm. I'm a Senior Director of Database Product Management here at Oracle. Let's start. Access control lists or ACLs, provide a mechanism to block all IP addresses that are not in specified list from accessing the database. Without access control lists specified by default, the database is accessible from any IP address. Now this could potentially be a problem if you're concerned with the fact that the system is publicly routable, and we'll talk about how you can change that as well. Once an ACL is setup though you need to be aware that the database will only accept connections from addresses that are in the list and all other client connections will be rejected. It also means that services that are subsets, for example, things like SQL Developer Web, Application Express, and OML Notebooks will also be blocked by these access control lists. Access control lists can be configured for an autonomous database at any time, either during provisioning or it can be added to an existing autonomous database. They can be configured for individual IP addresses, CIDR block ranges, as well as virtual cloud networks or VCNs, and setting all of these up can be done simultaneously. Also, a database restore does not override existing access control lists. Let's go over a quick demonstration on how to set up an access control list. Here we can see our ATP demo database is configured and we can see it's set up without any access control lists. In other words, it's disabled. To change that, we go to the More Actions drop-down and we choose Access Control Lists, and it will bring up this pop-up. In this case, you can see we could set it as being either IP, CIDR block, Virtual Cloud Network, or Virtual Cloud Network defined with an OCID or an Oracle Cloud ID, or it can be a combination of all of the above. In the first instance, I am going to specify an IP address and only users coming in through this IP address are allowed. We could add another entry. I can also say, I would also like to allow my application server that's running in my datacenter to access my database. In that case, we would specify the CIDR block range to allow that to take place. Let's say we've got some workloads running, perhaps some fusion applications, or maybe e-business suite running on a virtual computer somewhere in our virtual cloud subnet. We could choose a virtual cloud network and map that using our OCID or Oracle Cloud ID. Or we can map it using the name for the virtual cloud network. Click Save, and as you can see, we could set up all of the above. Now we can see that our access control list will now be listed as enabled. We've created a way to block anyone who's not in the whitelist from accessing our autonomous database. Some users may not want to allow the autonomous database to be publicly routable at all. This would be one way of ensuring that access or traffic to the autonomous database is completely kept off the public internet. We can do that using private endpoints. If you did have a Cloud service running in the Oracle Public Cloud, and you had an autonomous database, and you talk from one to the other using transit routing or other mechanisms, your traffic will never access the public internet. Even though your ADB is publicly routable, all traffic between your computer in the Cloud and the autonomous database would still be private. Private endpoints provide that mechanism. When doing this, you do not need to set up transit routing and your VCN to connect. This can also be done directly, and it can be configured either when you provision a new database or when you clone an existing database. You cannot go in and convert an existing autonomous database to your private endpoints, but you can make a clone of your autonomous database into a VCN and convert it to use private endpoints as long as it meets your requirements. Here are two examples where you might use private endpoints. One is if you've got a service running in the public Cloud and you want that service to talk directly to your ADB, but without showing anything is being publicly routable. Or two, it could also be for connecting an on-premise datacenter into your autonomous database and ensuring that no traffic would ever see your autonomous database because you're coming in through your private connection and the rest of that autonomous database access would be blocked from anyone outside. Doing this does require transit routing and a service gateway to be configured within your VCN. Think of this as just being another VNIC inside your VCN, which is a virtual network interface card within your VCN that you've defined. Before you can specify to use a private endpoint with your autonomous database, you need to make sure that you have a VCN within the region of your autonomous database. This cannot be changed after provisioning. You also need to ensure that you have a private subnet with default DHCP settings, and then at least one Network Security Group within your VCN. This could be changed or edited after you've provisioned it. There is some flexibility within the network security group. This is a brief architecture diagram of network security group. The network security groups create a virtual firewall for your autonomous database using security rules. Just as we created access controls to set up restrictions, we can do similar things with our security rules. Security rules provide a mechanism to allow certain ports either ingress or egress that's traffic coming in or traffic coming out of your Cloud Service. In the case of autonomous database, we're allowing an ingress of 1522. You can specify up to five NSGs to control access to your autonomous database. Here is a quick overview of the network security group details in our console. We see we've got our NSG defined, it has been set up and is named DEMO-NSG. To use an NSG with private endpoints for your autonomous database, we're setting an ingress TCP of 1522, which is the port that autonomous database listens on. To wrap up, I've showed you how you can control, access and protect the data that's in your autonomous database using access control lists and network security groups. Thanks for watching.
