Configuration: Network Isolation by Subnet

Use Case

Acme Company has decided to use the dedicated infrastructure feature of Autonomous Database on Dedicated Exadata Infrastructure for its internal project teams and lines of business. The Acme I.T. department will take on the role of fleet administrator, creating and managing all Exadata Infrastructure, Autonomous Exadata VM Cluster, and Autonomous Container Database resources for the company. Each project team or line of business will have users who take on the database administrator role for their organization, creating autonomous databases for their database users (application developers, testers and deployers).

Acme I.T. will allocate resources to the organizations, making sure to provide autonomous container databases that meet the SLAs required by them. Additionally, in order to control the allocation of the resources fairly, Acme I.T. does not want any project team or line of business to have management access to the underlying dedicated infrastructure. Even further, Acme management gets audited by regulators, so it does not want Acme I.T. to be able to access the data that belongs to the different project teams or lines of business; that is, the data they are putting into their application databases.

Two project teams are the first to come on board: Roadrunner and Coyote. Neither the Roadrunner project team nor the Coyote project team wants the other team to be able to access its work in any way.

Resulting Resources Needed

  • One VCN to provide network connectivity to all dedicated infrastructure resources. This VCN will connect to the Acme Company VPN using an IPSec VPN, and will have an Internet Gateway resource that blocks all incoming internet traffic. This VCN will be named DatabaseVCN.

  • Three private subnets in the VCN to provide network access isolation, one for Autonomous Database resources, and one for each team to use for their client and mid-tier resources. These subnets will be named ITSubnet, RoadrunnerSubnet and CoyoteSubnet.

  • Three compartments to provide resource isolation, one for the resources Acme I.T. creates and the private subnet those resources will use, and one each for the Roadrunner teams and Coyote teams for its autonomous databases and private subnet. These compartments will be named AcmeContainerDBs, RoadrunnerDBs and CoyoteDBs.

  • Three groups to which users can be assigned, one each for Acme I.T., the Roadrunner team and the Coyote team. These groups will be named AcmeFAs, RoadrunnerDBAs and CoyoteDBAs.

  • Three policies to specify user access to the resources in each of the compartments. These policies will be named AcmeContainerDBPolicy, RoadrunnerDBPolicy and CoyoteDBPolicy.

  • Two autonomous container databases, one that will be patched using Next RU (next release update) to provide stability and one that will be patched using Latest RU (latest release update) to provide access to the latest Autonomous Database features. These autonomous container databases will be named StableContainerDB and LatestContainerDB.

High-Level Steps

  1. The security administrator for Acme Company's cloud tenancy creates the AcmeContainerDBs, RoadrunnerDBs and CoyoteDBs compartments.

  2. The network administrator for Acme Company's cloud tenancy creates the DatabaseVCN VCN and the ITSubnet subnet in the AcmeContainerDBs compartment, and then creates the RoadrunnerSubnet and CoyoteSubnet subnets in the RoadrunnerDBs and CoyoteDBs compartments, respectively.

  3. The security administrator creates the AcmeFAs, RoadrunnerDBAs, and CoyoteDBAs groups.

  4. The security administrator creates the AcmeContainerDBPolicy, RoadrunnerDBPolicy, and CoyoteDBPolicy policies.

  5. After the network administrator finishes creating DatabaseVCN and ITSubnet, the security administrator adds the cloud user of a designated Acme I.T. member to the AcmeFAs group.

  6. The newly authorized fleet administrator creates an Exadata Infrastructure resource in the AcmeContainerDBs compartment.

  7. The fleet administrator then create an Autonomous Exadata VM Cluster resource in the AcmeContainerDBs compartment, specifying DatabaseVCN and ITSubnet as its VCN and subnet.

  8. The fleet administrator creates the StableContainerDB and LatestContainerDB Autonomous Container Database resources in the AcmeContainerDBs compartment, specifying the newly created Exadata Infrastructure and Autonomous Exadata VM Cluster as their underlying resources.

  9. The security administrator adds designated cloud users to the RoadrunnerDBAs group, thus authorizing them as database administrators for the Roadrunner project team, and then repeats the process for CoyoteDBAs.

Related Topics

Step 1. Create Compartments

In this step, the security administrator for Acme Company's cloud tenancy creates the AcmeContainerDBs, RoadrunnerDBs and CoyoteDBs compartments.

To perform this step, the security administrator follows the instructions in Managing Compartments in Oracle Cloud Infrastructure Documentation to create a compartment using the Oracle Cloud console. When following these instructions, the security administrator specifies the root compartment of the tenancy as the parent compartment of each of the three compartments.

Step 2. Create the VCN and Subnets

In this step, network administrator for Acme Company's cloud tenancy creates the DatabaseVCN VCN and the ITSubnet subnet in the AcmeContainerDBs compartment, and then creates the RoadrunnerSubnet and CoyoteSubnet subnets in the RoadrunnerDBs and CoyoteDBs compartments, respectively.

To perform this step, the network administrator first confers with the Acme I.T. department's networking to reserve a CIDR IP address range that will not conflict with the company's on-premises network. (Otherwise, the VCN would conflict with the on-premises network and an IPSec VPN could not be set up.) The reserved range is CIDR 10.0.0.0/16.

Then, the network administrator adapts the instructions in Scenario B: Private Subnet with a VPN in Oracle Cloud Infrastructure Documentation to create the VCN, the Subnets and other network resources using the Oracle Cloud console.

When adapting these instructions, the network administrator manually creates security lists (instead of using the default security lists) to isolate and separate security rules and thus make network management simpler. These security lists are:

  • ITSecList: the basic security list for ITSubnet. It is used when the ITSubnet subnet is created.
  • RoadrunnerSeclist: the basic security list for RoadrunnerSubnet. It is used when the RoadrunnerSubnet subnet is created.
  • RoadrunnerToITSeclist: a security list to permit resources in RoadrunnerSubnet to access Roadrunner team autonomous databases in ITSubnet. Once created, this security list is added to the ITSubnet subnet.
  • CoyoteSeclist: the basic security list for CoyoteSubnet. It is used when the CoyoteSubnet subnet is created.
  • CoyoteToITSeclist: a security list to permit resources in CoyoteSubnet to access Coyote team autonomous databases in the ITSubnet. Once created, this security list is added to the ITSubnet subnet.

Security Rules in the ITSecList Security List

Here are the ingress rules created in the ITSecList security list.

Stateless Source IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 10.0.0.0/24 ICMP     All ICMP traffic for: All
No 10.0.0.0/24 UDP All All   UDP traffic for ports: All
No 10.0.0.0/24 TCP All All   TCP traffic for ports: All

Here is the egress rule created in the ITSecList security list.

Stateless Destination IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 0.0.0.0/0 All Protocols     All All traffic for all ports

Security Rules in the RoadrunnerSeclist Security List

Here are the ingress rules created in the RoadrunnerSeclist security list.

Stateless Source IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 0.0.0.0/0 TCP All 22   TCP traffic for ports: 22 SSH Remote Login Protocol
No 0.0.0.0/0 TCP All 80   TCP traffic for ports: 80
No 0.0.0.0/0 TCP All 443   TCP traffic for ports: 443 HTTPS
No 0.0.0.0/0 TCP All 943   TCP traffic for ports: 943
No 0.0.0.0/0 UDP All 1194   UDP traffic for ports: 1194

Here is the egress rule created in the RoadrunnerSeclist security list.

Stateless Destination IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 0.0.0.0/0 All Protocols     All All traffic for all ports

Security Rules in the RoadrunnerToITSeclist Security List

Here are the ingress rules created in the RoadrunnerToITSeclist security list. Note that the source CIDR is 10.0.10.0/24, which is the CIDR of RoadrunnerSubnet.

Stateless Source IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 10.0.10.0/24 TCP All 1521   TCP traffic for ports: 1521
No 10.0.10.0/24 TCP All 2484   TCP traffic for ports: 2484
No 10.0.10.0/24 TCP All 443   TCP traffic for ports: 443 HTTPS
No 10.0.10.0/24 TCP All 6200   TCP traffic for ports: 6200

No egress rules are created in the RoadrunnerToITSeclist security list.

Security Rules in the CoyoteSeclist Security List

Note that the CoyoteSeclist security list has the same set of security rules as does RoadrunnerSeclist. While a single security list could be created and used for both project teams, the network administrator has created separate security lists in case one of the project teams requires additional security rules.

Here are the ingress rules created in the CoyoteSeclist security list.

Stateless Source IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 0.0.0.0/0 TCP All 22   TCP traffic for ports: 22 SSH Remote Login Protocol
No 0.0.0.0/0 TCP All 80   TCP traffic for ports: 80
No 0.0.0.0/0 TCP All 443   TCP traffic for ports: 443 HTTPS
No 0.0.0.0/0 TCP All 943   TCP traffic for ports: 943
No 0.0.0.0/0 UDP All 1194   UDP traffic for ports: 1194

Here is the egress rule created in the CoyoteSeclist security list.

Stateless Destination IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 0.0.0.0/0 All Protocols     All All traffic for all ports

Security Rules in the CoyoteToITSeclist Security List

Here are the ingress rules created in the CoyoteToITSeclist security list. Note that the source CIDR is 10.0.11.0/24, which is the CIDR of CoyoteSubnet.

Stateless Source IP Protocol Source Port Range Destination Port Range Type and Code Allows
No 10.0.11.0/24 TCP All 1521   TCP traffic for ports: 1521
No 10.0.11.0/24 TCP All 2484   TCP traffic for ports: 2484
No 10.0.11.0/24 TCP All 443   TCP traffic for ports: 443 HTTPS
No 10.0.11.0/24 TCP All 6200   TCP traffic for ports: 6200

No egress rules are created in the CoyoteToITSeclist security list.

Step 3. Create Groups

In this step, the security administrator creates the AcmeFAs, RoadrunnerDBAs and CoyoteDBAs groups.

To perform this step, the security administrator follows the instructions in Managing Groups in Oracle Cloud Infrastructure Documentation to create a group using the Oracle Cloud console.

Step 4. Create Policies

In this step, the security administrator creates the AcmeContainerDBPolicy, RoadrunnerDBPolicy and CoyoteDBPolicy policies.

To perform this step, the security administrator follows the instructions in Managing Policies in Oracle Cloud Infrastructure Documentation to create a policy using the Oracle Cloud console.

Note:

In addition to creating the required policy statements, in this example the security administrator also creates "USE tag-namespaces" policy statements to permit group members to assign existing tags to the resources they create. To permit group members to create tags as well as use existing tags, the security administrator would instead create "MANAGE tag-namespaces" policy statements.

When following these instructions for the AcmeContainerDBPolicy policy, the security administrator:

  1. Sets the Compartment in the side menu to AcmeContainerDBs before clicking Create Policy.

  2. Adds these Policy Statements:

    • Allow group AcmeFAs to MANAGE autonomous-exadata-infrastructures in compartment AcmeContainerDBs
    • Allow group AcmeFAs to MANAGE autonomous-container-databases in compartment AcmeContainerDBs
    • Allow group AcmeFAs to USE virtual-network-family in compartment AcmeContainerDBs
    • Allow group AcmeFAs to USE tag-namespaces in tenancy
    • Allow group RoadrunnerDBAs to READ autonomous-container-databases in compartment AcmeContainerDBs
    • Allow group CoyoteDBAs to READ autonomous-container-databases in compartment AcmeContainerDBs

When following these instructions for the RoadrunnerDBPolicy policy, the security administrator:

  1. Sets the Compartment in the side menu to RoadrunnerDBs before clicking Create Policy.

  2. Adds these Policy Statements:

    • Allow group RoadrunnerDBAs to MANAGE autonomous-databases in compartment RoadrunnerDBs
    • Allow group RoadrunnerDBAs to MANAGE autonomous-backups in compartment RoadrunnerDBs
    • Allow group RoadrunnerDBAs to USE virtual-network-family in compartment RoadrunnerDBs
    • Allow group RoadrunnerDBAs to MANAGE instance-family in compartment RoadrunnerDBs
    • Allow group RoadrunnerDBAs to USE tag-namespaces in tenancy

When following these instructions for the CoyoteDBPolicy policy, the security administrator:

  1. Sets the Compartment in the side menu to CoyoteDBs before clicking Create Policy.

  2. Adds these Policy Statements:

    • Allow group CoyoteDBAs to MANAGE autonomous-databases in compartment CoyoteDBs
    • Allow group CoyoteDBAs to MANAGE autonomous-backups in compartment CoyoteDBs
    • Allow group CoyoteDBAs to USE virtual-network-family in compartment CoyoteDBs
    • Allow group CoyoteDBAs to MANAGE instance-family in compartment CoyoteDBs
    • Allow group CoyoteDBAs to USE tag-namespaces in tenancy

Step 5. Assign Fleet Administrators

In this step, the security administrator adds the cloud user of a designated Acme I.T. member to the AcmeFAs group.

To perform this step, the security administrator follows the instructions in Managing Users in Oracle Cloud Infrastructure Documentation to add a user to a group using the Oracle Cloud console.

Step 6. Create the Exadata Infrastructure Resource

In this step, the fleet administrator follows the instructions in Create an Exadata Infrastructure Resource to create an Exadata Infrastructure resource in the AcmeContainerDBs compartment.

Step 7. Create the Autonomous Exadata VM Cluster Resource

In this step, the fleet administrator follows the instructions in Create an Autonomous Exadata VM Cluster to create an Autonomous Exadata VM Cluster Infrastructure resource in the AcmeContainerDBs compartment, specifying DatabaseVCN and ITSubnet as its VCN and subnet.

Step 8. Create Autonomous Container Database Resources

In this step, the fleet administrator follows the instructions in Create an Autonomous Container Database to create the StableContainerDB and LatestContainerDB Autonomous Container Database resources in the AcmeContainerDBs compartment, specifying the newly created Exadata Infrastructure and Autonomous Exadata VM Cluster as their underlying resources. When creating StableContainerDB, the fleet administrator configures its database maintenance version to Next RU (next release update). When creating LatestContainerDB the fleet administrator configures its database maintenance version to Latest RU (latest release update) and changes the Backup retention policy from its default of 7 Days to 30 Days.

Step 9. Assign Database Administrators

In this step, the security administrator adds designated cloud users to the RoadrunnerDBAs group, thus authorizing them as database administrators for the Roadrunner project team, and then repeats the process for CoyoteDBAs.

To perform this step, for each user the security administrator follows the instructions in Managing Users in Oracle Cloud Infrastructure Documentation to add a user to a group using the Oracle Cloud console.