Learn About Network Security

A secure network is key to protecting your organization from being vulnerable to cyber-threats. Designing a network that is founded on best practices and a secure framework can make your deployment resilient to threats and attacks.

Use the CIS OCI Landing Zone Quick Start Template

The Center for Internet Security (CIS) is a community-driven nonprofit organization that has created CIS Controls and CIS Benchmarks to help customers secure their IT systems and data across different vendors and environments. CIS Benchmarks are best practices for the secure configuration of a target system and are developed through a unique consensus-based process comprised of cybersecurity professionals and subject matter experts around the world.

Oracle provides a CIS OCI Landing Zone Quick Start Template that enables you to quickly implement the CIS OCI Foundations Benchmark and overall OCI best practices within their tenancy.

The CIS OCI Landing Zone Quick Start Template enables you to quickly deploy the core infrastructure needed for your tenancy while meeting the CIS OCI Benchmarks. Some of the resources that the CIS OCI Landing Zone Quick Start Template helps you deploy and configure are:

• OCI Identity and Access Management (IAM)
• OCI Logging
• OCI Events
• OCI Notifications
• OCI Object Storage
• Oracle Key Vault
• Networking
• Compartments
• Cloud Guard
• Vulnerability Scanning

Use Network Security Groups (NSGs)

Security lists let you define a set of security rules that apply to all the virtual network interface cards (VNICs) in an entire subnet. Network Security Groups (NSG) provide more granular filtering and control of traffic flowing to and from an individual or group of VNICs controlled by the NSG. An NSG approach allows you to implement a microsegmentation strategy inside OCI and reduce the total attack surface of a network security incident.

As an example, if you allow Secure Shell (SSH) in a security list rule you will end up allowing SSH to all VNICs in that subnet. Allowing SSH in a NSG will only allow it to the VNICs that are associated with that NSG, if there is no rule in the corresponding security list.

Tip:

When mixing both NSG and security lists together, the union of the two is enforced. This means that a packet in question is allowed if any rule in any of the relevant security lists or NSG allows the traffic. For example, if your security list allows SSH from all sources (0.0.0.0/0) but your NSG does not, the VNICs in that subnet and associated with that NSG will permit SSH from all sources because the SL rule allows it.

Oracle recommends the following:

• Use NSGs for components that all have the same security posture because Oracle prioritizes NSGs over SLs when implementing future enhancements. For example, in a multitier architecture, you should have a separate NSG for each tier. A given tier's VNICs would all belong to that tier's NSG. Within a given tier, you might have a particular subset of the tier's VNICs that have additional, special security requirements. Therefore, you should create another NSG for those additional rules, and place that subset of VNICs into both the tier's NSG and the additional NSG.
• Create NSGs for specific groups of resources that have the same traffic flow requirements, such as NSG for each tier of an application.
• Take an allowlist approach to all SL and NSG rules and only allow the specific sources, protocols, and ports required by your application or workload.
• Avoid allowing large sources, protocols, and ports because you'e unsure about the specific requirements.
• If you do allow large sources, protocols, and ports, only do so temporarily (such as for troubleshooting) and lock them down later.

Tip:

When temporarily allowing traffic in an NSG or SL, such as adding a temporary rule for troubleshooting, add a note in the rule description to indicate that this is temporary and can be deleted later. This reminds you to remove the rule when ready or when you're unsure if it's needed in future reviews.

Use the OCI Bastion Service

The OCI Bastion service provides an alternative method to securely access your resources compared to the traditional method of deploying a bastion host in a public subnet. Oracle recommends the OCI Bastion service due to the following benefits:

• Lower cost
• Integrates with OCI IAM for seamless control and restricting access
• Less complexity (no public subnet or host needed)
• Bastion sessions are time-limited
• OCI managed service
• Administrative actions like who/when/created/deleted/updated/fetched are recorded and logged in OCI Events and Audit service

The following diagram illustrates this reference architecture.

Description of the illustration architecture-use-bastion-service.png

Oracle recommends the following:

• Familiarize yourself with the OCI Bastion service and use it instead of provisioning a bastion host in a public subnet
• Lock down access to the OCI Bastion service using IAM policies

Implement Least-Privileged Management Access with IAM Policies

The OCI IAM service lets you control who has access to your cloud resources. You can control what type of access a group of users has and to which specific resources.

Network resources that you provision inside of OCI are typically part of the core building blocks in your architecture that your applications and workloads depend on. Restricting access to these network resources is an important part of your OCI security and IAM design to help prevent unauthorized users from creating or changing resources that could lead to downtime or security holes.

Oracle recommends the following:

• Start with the simplest approach by creating a policy to only allow network admins to manage a cloud network.
• A advanced approach is to create policies to restrict access to individual network resources. For example, create separate policies to let one group of admins manage the Dynamic Routing Gateways (DRG), and another group of admins to manage Virtual Cloud Networks (VCN).
• Consider the need for read-only policies that are necessary for non-network admins to have access to, such as:
  • Network Visualizer
  • Network Path Analyzer
• Limit the usage of the use and manage verbs in your IAM policies for the virtual-network-family.
• OCI network IAM policies and design should be a part of your overall OCI IAM policy and design.

Consider Deploying the OCI Network Firewall or a Third-Party Firewall

If you have network security requirements that require more functionality than what the native SLs or NSGs in OCI provide, then OCI recommends that you deploy either the OCI Network Firewall or a third-party firewall.

Firewalls typically bring next-generation capabilities such as intrusion detection and prevention (IDPS), URL filtering, and Secure Socket Layer (SSL) inspection.

The following diagram illustrates north-south outbound internet traffic flow using a NAT Gateway and through the OCI Network Firewall in a secured VCN:

Description of the illustration oci-network-firewall-outbound-nat.png

Oracle recommends the following:

• Ask your preferred third-party firewall vendor if they support their platform on OCI.
• Investigate if using the native OCI Network Firewall meets your requirements.
• Use the hub-and-spoke VCN design and place the firewall(s) in a hub VCN. Use a DRG to route the traffic through the firewalls.
• Analyze the impact to network performance by routing traffic through a firewall in OCI, such as throughput and latency.