1. Concepts Guide
  2. Virtual Networking Overview
  3. Network Security

Network Security

This section provides information about controlling access and security in your cloud network. The firewall functionality inside a VCN is described in detail in Virtual Firewall. Additional topics about secure network access are discussed here.

Ways to Secure Your Network

There are several mechanisms to control security for your cloud network and compute instances:

  • Private subnets: If instances do not require a public IP address, you can designate a subnet to be private, to prevent instances from obtaining a private IP.

  • Firewall rules: To control packet-level traffic into and out of an instance, you can configure firewall rules directly on the instance itself. Images provided with Private Cloud Appliance that run Oracle Linux automatically include default rules that allow ingress on TCP port 22 for SSH traffic. Also, Microsoft Windows images may include default rules that allow ingress on TCP port 3389 for Remote Desktop access.

  • Gateways and route tables: To control general traffic flow from your cloud network to outside destinations – the internet, your on-premises network, or another VCN – you configure your cloud network's gateways and route tables to allow only the connectivity that is effectively required.

  • IAM policies: You can control who has access to the Private Cloud Appliance interfaces. You can control which cloud resources can be accessed and which type of access is allowed. For example, you can control who can set up your network and subnets, or who can update route tables, network security groups, or security lists.

Access Control

This topic provides basic information about using compartments and IAM policies to control access to your cloud network.

Using Compartments with Network Resources

Whenever you create a cloud resource such as a virtual cloud network (VCN) or compute instance, you must specify which IAM compartment you want the resource to be in. A compartment is a collection of related resources that can only be accessed by certain groups that have been given permission by an administrator in the tenancy. The administrator creates compartments and corresponding IAM policies to control which users in your organization access which compartments. Ultimately, the goal is to ensure that users can only access the resources they need.

In an enterprise production environment, you typically divide the tenancy into multiple compartments to more easily control access to certain types of resources. For example, your administrator could create Compartment_A for your VCN and other networking components. The administrator could then create Compartment_B for all the compute instances and block storage volumes that the HR department uses, and Compartment_C for all the instances and block storage volumes that the Marketing department uses.

The administrator would then create IAM policies that give users only the level of access they need in each compartment. For example, HR instance administrators are not entitled to modify the existing cloud network. So they would have full permissions for Compartment_B, but limited access to Compartment_A: only what is required to launch instances into the network. If they try to modify other resources in Compartment_A, the request is denied.

Network resources such as VCNs, subnets, route tables, security lists, service gateways, and NAT gateways can be moved from one compartment to another. When you move a resource to a new compartment, inherent policies apply immediately.

Detailed information about the use of compartments, and how to control access to your cloud resources, is provided in the chapter Identity and Access Management Overview. More specifically, refer to Organizing Resources in Compartments and How Policies Work.

Using IAM Policies for Networking

A convenient and common approach to granting access to Networking is to grant permission to a Network Administrators group to manage the VCN and all related networking components: subnets, security lists, route tables, gateways, and so on. It is useful to also allow the Network Administrators to launch instances in order to test network connectivity. Both policies – to manage network resources and to launch instances – are covered in Common Policies. The required policy statements should look similar to this example: 

Allow group NetworkAdmins to manage virtual-network-family in tenancy
Allow group NetworkAdmins to manage instance-family in compartment ABC
Allow group NetworkAdmins to use volume-family in compartment ABC

If you are not yet familiar with IAM policies, refer to How Policies Work in the chapter Identity and Access Management Overview.

If you prefer a finer-grained approach to access control, you can write policies that focus on individual resource types. For example, the virtual-network-family resource type includes individual resource types such as subnets, route-tables, security-lists or local-peering-gateways. You can grant specific access to these by writing separate policies per resource type.

In addition, you can write policies that limit the level of access by using a different policy verb; for example: manage versus use, and so on. If you do, there are some nuances to understand about the policy verbs for Networking.

Be aware that the inspect verb not only returns general information about the network components; for example, the name and OCID of a security list or route table. It also includes the contents of the component; for example, the actual rules in the security list, the routes in the route table, and so on.

Also, the following operations are available only with the manage verb, not the use verb:

  • Update (enable/disable) internet-gateways

  • Update security-lists

  • Update route-tables

  • Update dhcp-options

  • Attach a DRG to a VCN

  • Peer two VCNs

Each VCN has various components that directly affect the behavior of the network: route tables, security lists, DHCP options, internet gateway, and so on. When you create one of these components, you establish a relationship between that component and the VCN, which means you must be allowed in a policy to both create the component and manage the VCN itself. However, the ability to update that component – to change the route rules, security list rules, and so on – does NOT require permission to manage the VCN itself, even though changing that component can directly affect the behavior of the network. This discrepancy is designed to give you flexibility in granting least privilege to users, and not require you to grant excessive access to the VCN just so the user can manage other components of the network. Be aware that by giving someone the ability to update a particular type of component, you are implicitly trusting them with controlling the network's behavior.