Securing Oracle Cloud Linux Instances: Security Lists vs Network Security Groups (NSGs)

 

🔹 Introduction

When launching Oracle Linux compute instances or database systems in Oracle Cloud Infrastructure (OCI), security is a top priority. Two critical features that control network access in OCI are:

• 🔸 Security Lists

• 🔸 Network Security Groups (NSGs)

Many admins and even some Oracle DBAs are unclear about when to use which. In this post, I’ll explain both in a simple, real-world scenario that applies directly to database environments.

🔹 What You'll Learn

• What are Security Lists and NSGs

• Key differences between the two

• Best use cases for each

• A working example: Allowing access to Oracle DB port 1521

• My personal recommendation as a DBA

🔹 1. What is a Security List?

A Security List is attached to a Subnet in OCI. All compute instances in that subnet inherit its rules.

Example Rule:
Allow Ingress TCP Port 22 from CIDR 0.0.0.0/0 (for SSH access)

🔹 2. What is a Network Security Group (NSG)?

An NSG is like a mini-firewall attached to a specific instance or resource, not to the whole subnet.

It gives resource-level granularity, especially useful when multiple DB or app servers are in the same subnet.

🔸 Key Differences

Feature	Security List	Network Security Group (NSG)
Attached To	Subnet	Individual resources (VM, DB System)
Granularity	Broad (all in subnet)	Fine-grained (specific resource)
Rule Changes	Affects all in subnet	Only affects attached resource
Use Case	Simpler setups	Secure and complex architectures
Default for DB Systems	Often not editable	Fully supported and flexible

🔹 3. Real-World Use Case: Allow DB Port 1521 for a Specific App Server

🔧 Scenario: You want to allow only one application server to access the DB port 1521 on your Oracle Database system in OCI.

✅ Option 1: Security List Approach

• Add Ingress Rule:

  • Protocol: TCP

  • Port: 1521

  • Source CIDR: <AppServer-IP>/32

🔴 Problem: Any other compute instance in the subnet can also use this rule.

✅ Option 2: NSG Approach (Recommended)

• Create NSG: nsg-db-access

• Add Ingress Rule:

  • Protocol: TCP

  • Port: 1521

  • Source: Another NSG (e.g., nsg-app-server)

• Attach this NSG only to the DB instance

✔️ Advantage: Only the app server can talk to the DB. More secure and flexible.

🔹 4. How to Create NSGs (via Console)

1. Go to Networking → Network Security Groups → Create

2. Name: nsg-db-access

3. Add rule: Ingress TCP Port 1521 from nsg-app-server

4. Attach this NSG to your DB system under its Network settings

🔹 Best Practices

• ✅ Use NSGs for DB systems, always

• ✅ Create separate NSGs for App, DB, Web tiers

• ✅ Keep Security Lists for basic subnet rules like SSH

• 🚫 Avoid using wide CIDR blocks (0.0.0.0/0) for database ports

💡 Vignesh’s Tip

You can automate NSG rule creation using OCI CLI:

oci network nsg-rule add --nsg-id ocid1.networksecuritygroup.oc1... \
--direction INGRESS --protocol 6 --is-stateless false \
--source-type NETWORK_SECURITY_GROUP --source-id ocid1.networksecuritygroup.oc1... \
--tcp-options '{"destinationPortRange": {"min": 1521, "max": 1521}}'

This is very useful when provisioning resources via scripts or Terraform.

🔹 Conclusion

Security Lists and NSGs both play crucial roles in OCI, but understanding their differences helps you build secure and modular cloud environments. For Oracle DBAs, using NSGs for database port control is a best practice.