When you design a secure multitier network, build the architecture in layers.
Place your most sensitive resources, such as the databases, in the innermost layer in private subnets. Define security rules to control network access to the resources. Route traffic from the public internet through bastion hosts and load balancers.
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.
- 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.
- 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|
||TCP/22 to the VCN|
||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.
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
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.
|xxx_yyy_Networks||None||VCN and gateways|
|xxx_yyy_Admin||DMZ subnet||Bastion hosts|
|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.
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:
Note: Oracle creates the
||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).|
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.