- Quick answer: OCI Security Lists vs Network Security Groups
- Security Lists (SL) apply at the subnet level — every resource in that subnet inherits the same rules. Best for baseline, uniform policies across identical workloads.
- Network Security Groups (NSG) apply at the VNIC level — granular control where rules reference other NSGs instead of IP addresses. Best for enterprise microsegmentation and zero-trust tiers.
- Critical: SLs and NSGs use OR (union) logic — if either allows traffic, it passes. Tighten both layers.
01 · The Security Audit Nobody Expected to Fail
Your architecture diagram looks immaculate. Production workloads sit in private subnets with absolute zero public IPs. You have separated your environments cleanly, convinced that organization equals security.
Then comes the security audit. As the security team digs into the live OCI environment, a sobering reality emerges:
- An application server in staging has a direct SQL path to a production database
- A temporary troubleshooting rule opened six months ago is still wide open
- Development instances are routinely talking to production shared services
- Nobody knows which security rules can be safely deleted
"But everything is in a private subnet," someone protests.
Here is the hard truth: Network topology is not a security boundary. Designing a clean Virtual Cloud Network (VCN) layout gets the architectural glory, but micro-level configuration determines actual defense. The most catastrophic security failures in OCI rarely stem from an engineer accidentally attaching an Internet Gateway to a database. They happen because of overly broad, unmanaged security rules operating silently inside your private networks.
02 · OCI Security Lists vs. Network Security Groups: What's the Difference?
OCI provides two primary tools to govern VNIC traffic. While they both filter ingress and egress traffic, their scope is fundamentally different.
| Attribute | Security List (SL) | Network Security Group (NSG) |
|---|---|---|
| Scope | Subnet level — all VNICs in the subnet inherit rules | VNIC level — attached per resource |
| Best for | Baseline security, identical workloads at scale | Granular zero-trust, tier-based microsegmentation |
| Source/Destination | CIDR blocks, IP addresses | CIDR blocks, IPs, other NSGs |
| Trade-off | Zero granularity — specialized tools inherit blanket rules | Operational complexity without automation/Terraform |
Security Lists (SL): The Subnet Blanket
A Security List applies at the subnet level. Every resource attached to that subnet automatically inherits its rules.
Advantage: Great for baseline security. If you have 50 identical web servers in one subnet requiring the exact same rules, an SL manages them globally.
Disadvantage: Zero granularity. If you deploy a specialized management tool into that subnet, it inherits those same 50 rules unless you build a brand-new subnet.
Network Security Groups (NSG): The Resource Shield
An NSG applies directly to the VNIC level. It secures the specific resource, regardless of its subnet.
Advantage: Granular, zero-trust control. You can write rules where the source or destination is another NSG, completely eliminating hardcoded IP addresses.
Disadvantage: Managing dozens of highly specific NSGs can introduce operational complexity if you lack a solid automation or Terraform strategy.
Figure 1 · Security Lists (subnet blanket) vs Network Security Groups (VNIC shield)
03 · Which One Should You Use? Defense in Depth
Choosing between them isn't an all-or-nothing decision. The most resilient OCI architectures utilize both in a defense-in-depth model.
Security Lists Keep It Simple
If you are managing a simple environment with a few Compute instances, Security Lists keep your configuration centralized and easy to read.
NSGs Are Non-Negotiable
For complex environments, NSGs are essential. Group resources into Load-Balancer-NSG, App-Server-NSG, and DB-NSG. Rules become clean policy: App-Server-NSG allows ingress on port 8080 only if the source is Load-Balancer-NSG.
Listing 1 · OCI Terraform security rule referencing NSG instead of CIDR — a core OCI Terraform security pattern
04 · Why Do Teams Accidentally Expose Databases?
How does a database inside a private subnet, with zero direct internet access, end up exposed to unauthorized internal systems? It boils down to the overuse of broad CIDR blocks and shared Security Lists.
Figure 2 · Broad CIDR rules bypass subnet segregation — dev instances reach production databases
An administrator configures a rule inside the database Security List that reads: Allow Ingress on Port 1521 from Source 10.0.0.0/16 (the entire VCN).
Because 10.0.0.0/16 is an internal private network, it feels safe. But you have just bypassed your subnet segregation. If a developer launches a temporary instance in a development subnet within that VCN, that instance instantly gains a direct network path to your production database port.
Why It's Painful to Fix Later
Over time, applications develop invisible dependencies on these wide-open paths. If you suddenly replace a broad VCN-wide rule with a restrictive NSG, you risk breaking undocumented legacy tools or backup agents. Because nobody knows exactly what will break, engineers become terrified of cleaning up old rules. The broad access remains open indefinitely.
Replace 10.0.0.0/16 with an NSG reference: DB-NSG accepts port 1521 only from App-Server-NSG. No IP addresses. No environment bleed. Self-updating as instances scale.
05 · How Does Stateful Traffic Actually Work?
By default, almost every security rule you create in OCI is stateful. A stateful rule means that once a connection is allowed to initiate in one direction, OCI automatically remembers it and permits the corresponding return traffic. No reverse rule is required.
Figure 3 · Stateful traffic — OCI tracks active sessions and permits return packets automatically
1 · Inbound Request
A load balancer sends an HTTP request to an app server. The app server's NSG has a stateful ingress rule allowing port 8080. The packet enters.
2 · Tracking
OCI's virtual networking layer logs this active connection in an internal state table.
3 · Outbound Response
When the app server responds, OCI checks the table, recognizes the active session, and lets the response pass.
Stateless rules, by contrast, do not track connection state. If you use a stateless ingress rule, you must write a corresponding stateless egress rule for the return traffic. Stick to stateful rules unless you are running massive, ultra-low-latency big data clusters that demand bypassing the state table.
06 · What Security Model Does Oracle Recommend?
Oracle recommends a layered, zero-trust security model centered around NSG-based segmentation — a pattern that maps directly to OCI network security best practices for production estates.
| Tier | NSG Policy | Ports |
|---|---|---|
| Web / Load Balancer | Accept traffic strictly on public web ports | 443, 80 |
| Application | Ingress only if source is Web/LB NSG | 8080, 8443 |
| Database | Ingress only if source is Application NSG | 1521 (Oracle), 3306 (MySQL) |
With this model, a database doesn't care what subnet it sits in. Unless an inbound packet carries the explicit identity of the Application Tier NSG, the virtual network drops it instantly. This is OCI microsegmentation done correctly — identity-based, not location-based.
07 · The Union Catch: OR Logic Between SLs and NSGs
In OCI, Security Lists and Network Security Groups do not combine with AND logic. They form a union (OR). If either the subnet's Security List or any attached NSG allows a packet, the traffic is permitted.
This catches teams constantly. An architect deploys a beautifully restrictive DB-NSG that only allows port 1521 from App-Server-NSG — then wonders why a dev instance in another subnet can still reach the database. The answer: the subnet's Security List still has that old 10.0.0.0/16 rule, and the union logic lets it through.
You cannot use a restrictive NSG to override a permissive Security List. Both layers must be tightened. When auditing, review Security Lists and NSGs together — not in isolation.
08 · The Short Version — 6 Security Decisions That Prevent Future Problems
- Private subnets are not security controls.They prevent public routes; they do not stop unauthorized internal lateral movement.
- Security Lists protect subnets; NSGs protect workloads.Use SLs for broad baselines, NSGs for granular application control.
- Reference NSGs, not IPs.Let your NSGs point to other NSGs to build self-updating, dynamic firewalls.
- Avoid broad CIDR rules.Never open application or database ports to an entire /16 or /24 block out of convenience.
- Apply least privilege early.It is much easier to grant access later than to claw back loose rules once production is live.
- Review and clean up regularly.Treat security rules like code. Track temporary troubleshooting rules and delete them when done.
09 · Frequently Asked Questions
What is the difference between OCI Security Lists and Network Security Groups?
Security Lists apply at the subnet level — every resource in that subnet inherits the same rules. Network Security Groups apply at the VNIC level, giving granular control where rules can reference other NSGs instead of hardcoded IP addresses.
Should I use Security Lists or NSGs in OCI?
Use both. Security Lists for subnet-wide baselines in simple environments; NSGs for enterprise multi-tier applications where you need microsegmentation — for example, App-Server-NSG allows port 8080 only from Load-Balancer-NSG.
Do Security Lists and NSGs use AND or OR logic?
OR (union) logic. If either the subnet Security List or any attached NSG allows a packet, it is permitted. A restrictive NSG cannot block traffic that a permissive Security List already allows.
Are OCI security rules stateful by default?
Yes. Stateful rules track active connections and automatically permit return traffic. Stateless rules require explicit reverse rules and are only recommended for ultra-low-latency big data workloads.
Why do databases in private OCI subnets still get exposed?
Broad CIDR rules like allowing port 1521 from an entire VCN (10.0.0.0/16) bypass subnet segregation. Any instance anywhere in that VCN can reach the database, and over time undocumented dependencies make these rules terrifying to remove.
Conclusion: Topology Is Not Security
Locking down internal workloads with the right mix of Security Lists and NSGs ensures your blast radius is tightly contained. Private subnets are necessary — but they are not sufficient.
But once your internal environment is locked down under a zero-trust model, you hit the next structural hurdle: private workloads still need to pull patches, reach OCI Object Storage, and communicate with external APIs. How do you handle that connectivity without exposing your systems? Read next: Why Private OCI Instances Still Need Internet Access — where we break down the exact architectural use cases for Internet, NAT, and Service Gateways.