Design a Secure Multitier Network

Determine Your Subnet Strategy

A subnet is a contiguous range of IP addresses within a VCN. To control network traffic to and from a subnet, you can attach security lists, a route table, and a set of DHCP options.

Consider the following factors when determining your subnet strategy:

You can't change the size of a subnet after creating it. So plan the sizes of all the subnets that you need before you create them.
A subnet can be private or public. You make this choice when you create the subnets, and you can't change it later.
A typical strategy is to create only private subnets.
- Traffic from your on-premises network can use an IPSec VPN connection or an Oracle Cloud Infrastructure FastConnect link.
- Traffic from the public internet can be routed through a public load balancer.
- Traffic bound for the public internet can be routed through a network address translation (NAT) gateway. The NAT gateway allows resources in a private subnet to make outbound connections to the internet and to receive data on the same connection. It doesn't allow inbound connections from the internet.
If your application architecture requires public IP addresses (for example, when you are migrating an on-premises application to the cloud), use an architecture that contains both private and public subnets.
Create the subnets in the compartments where you plan to provision the resources that need the subnets.
A subnet can be either specific to an availability domain (AD) or regional. AD failures don't affect regional subnets.

Design Security Lists

For each of your subnets, you can create security rules that specify the source, destination, and type of traffic that must be allowed into and out of the subnet. You define these rules in security lists and attach the security lists to the subnets.

To implement granular control over ingress and egress network traffic, you can create security lists for individual subnets. You can keep rules that are common to all the subnets in a separate (global) security list. The following are a few types of security lists that you can consider:

Global security list: This security list contains the rules that you want to use for all the subnets. Typically, this list contains few rules.
Tier-specific security list: You can define security lists for particular tiers in the multitier architecture (for example, the business logic or the database tier). By designing your subnets carefully, you can greatly reduce the number of security rules that are needed for inter-tier communication. For example, you can allow the business logic tier to communicate with the database tier by creating just two security rules (one ingress and one egress).
Family security list: This list is for the security rules that apply to the subnets that make up a single service or that are for a single customer within an availability domain. For example, the rules that apply to the web, application, and load balancer service subnets within an availability domain in the business logic tier.
Subnet-specific security lists: These lists contain rules that are specific to individual subnets.
Temporary security list: You can use a temporary security list for rules that you are experimenting with or testing. For example, while testing a specific ingress use case, you can create the required rules in a temporary security list.

Define Security Rules

Use security rules to control network traffic to and from your resources. Each rule defines the direction, source, destination, port, and protocol for which traffic is allowed.

The following table is an example of the rules that you should define per subnet family. Determine the rules that your applications require.

Subnet Family	Ingress Rules	Egress Rules
DMZ	TCP/22 from anywhere TCP/80 from anywhere TCP/443 from anywhere	TCP/22 to the VCN
Load balancer	TCP/80 from anywhere TCP/443 from anywhere	TCP/80 to the middle tier TCP/443 to the middle tier
Middle tier	TCP/80 from the load balancer TCP/443 from the load balancer	TCP/1521 to the database tier
Database	TCP/1521 from the middle tier	None

Note:

Defining security lists and rules is the first step in securing your network. Before you expose your network to the internet, consider how to address distributed denial of service (DDoS), SQL injection, and other network attacks.

Define Compartments

Use compartments to organize your cloud resources in logical containers and to control access to the resources. The policies that you define control the users' ability to create and manage resources in specific compartments.

Design your compartments and policies based on how your cloud resources are managed. The goal is to ensure that users have access to only the resources that they need based on their business and IT roles. For example, if one group of users manages the middle tier and another group manages the database tier, then create a compartment for each tier. Even if only one human user manages both the tiers, consider using a separate compartment for each tier. This approach enables you to segregate the permissions easily when required.

Compartments also enable you to track and manage the usage of your cloud budget. For example, you can create a compartment for each department in your organization, and monitor the cloud resources in each compartment.

Assign logical names to your compartments. Use a naming convention that enables you to easily identify the nature and state of the resources in the container.

The following table provides an example of the compartments and subnets structure for a typical multitier architecture. In this example, xxx in the compartment name could (for example) be Dev, Test, Stage, or Prod; and yyy could be the name of your application or workload. For example, the name Prod_Ordering_SharedServices indicates that the compartment contains production resources used by the shared services of the Ordering application.

Compartment	Subnets	Resources
xxx_yyy_Networks	None	VCN and gateways
xxx_yyy_Admin	DMZ subnet	Bastion hosts
xxx_yyy_BusinessLogic	Web-server subnets Application-server subnets Load-balancer subnets	Web-server instances Application-server instances Load-balancer nodes
xxx_yyy_Database	Database subnets	Database instances
xxx_yyy_SharedServices	Shared services subnets	Shared components

Create the virtual cloud network and its gateways in the xxx_yyy_Networks compartment, and create the required subnets in the other compartments.

Create Users

Each person or system that needs to create or manage resources must be defined as a user in Oracle Cloud Infrastructure Identity and Access Management (IAM) or in a federated identity provider. Create the required users.

When you sign up for an Oracle Cloud account, Oracle sets up an administrator user and assigns the user to a group called Administrators. You can't delete this group. You can add more users to it. A predefined policy allows the Administrators group to manage all the resources in Oracle Cloud Infrastructure.

Create the required users. If your account uses a federated identity provider (for example, Oracle Identity Cloud Service), then create the users in that identity provider.

If your federated users need the ability to manage API keys and authentication tokens, then ensure that the federated identity provider is configured to provision users in IAM. (This configuration is required only for accounts that were created before December 21, 2018.) Alternatively, create a local user in IAM.

Plan Your Groups and Policies

You can control a user's permissions by adding the user to a group or by removing the user from a group. Plan the required groups and the policies to allow the groups to manage the resources in specific compartments.

You can assign a user to one or more groups. Policies govern access to the Oracle Cloud Infrastructure resources. A policy specifies the permissions for one or more groups, users, or compartments.

The following table lists the groups and permissions required, typically, for a multitier architecture:

Group	Permissions
`DBAdmins`	Read all the resources in the tenancy. Manage the database resources.
`IAMAdminManagers`	Manage users. Manage the `Administrators` and `NetSecAdmins` groups. Note: Oracle creates the `Administrators` group when you subscribe to Oracle Cloud. The users in this group have full access to all the resources in the tenancy, including managing users and groups. Limit the membership to this group.
`IAMManagers`	Manage users. Manage all the groups except `Administrators` and `NetSecAdmins`.
`NetworkAdmins`	Read all the resources in the tenancy. Manage all the networking resources, except security lists, internet gateways, IPSec VPN connections, and customer-premises equipment.
`NetSecAdmins`	Read all the resources in the tenancy. Manage security lists, internet gateways, customer-premises equipment, IPSec VPN connections, and load balancers. Use all the virtual network resources.
`ReadOnly`	View and inspect the tenancy. This group is for users who aren't expected to create or manage any resources (for example, auditors and trainees).
`StorageAdmins`	Read all the resources in the tenancy. Manage the object storage and block volume resources.
`SysAdmins`	Read all the resources in the tenancy. Manage the compute and storage resources. Manage compartments. Use load balancers, subnets, and VNICs.

In your federated identity provider (for example, Oracle Identity Cloud Service), you must create the required groups and map each group to the corresponding group in Oracle Cloud Infrastructure Identity and Access Management.