11.1 Layered Network Security: Security Lists, NSGs & Private Access to Services

8.1 Layered Network Security: Security Lists, NSGs & Private Access to Services

Subnet-Level Filtering vs. VNIC Micro-Segmentation

In Oracle Cloud Infrastructure, network packet filtering can be enforced at two distinct logical boundaries: the Subnet boundary via Security Lists, or the Virtual Network Interface Card (VNIC) boundary via Network Security Groups (NSGs).

Security Lists (Subnet-Level)

Security Lists are assigned to entire subnets. When a Security List is attached to a subnet, its ingress and egress rules apply uniformly to every single VNIC provisioned within that subnet. An architect can associate up to 5 Security Lists with a single subnet.

While simple to configure for homogenous workloads, Security Lists impose significant design limitations:

• No Intra-Subnet Isolation: If a subnet contains both web servers and database instances, Security Lists cannot prevent a compromised web server from attacking the database on port 1521, because all instances inherit the same rules.
• Subnet Sprawl: To achieve tier-by-tier isolation using Security Lists, architects are forced to carve VCNs into numerous small subnets (e.g., Web Subnet, App Subnet, DB Subnet, Management Subnet), creating routing overhead and address space fragmentation.

Network Security Groups (VNIC-Level Micro-Segmentation)

Network Security Groups (NSGs) decouple security policies from network topology. An NSG consists of ingress and egress security rules applied directly to individual VNICs, regardless of which subnet the VNIC resides in. An architect can attach up to 5 NSGs to a single VNIC.

NSGs provide decisive architectural advantages:

• Micro-Segmentation: Compute instances, load balancers, and database systems residing in the exact same subnet can belong to distinct NSGs with entirely different security postures.
• Simplified Subnet Architecture: Workloads can reside within large, consolidated subnets (e.g., a single /22 subnet across an entire Availability Domain), with security boundaries defined logically via NSGs.

---

Using NSGs as Rule Sources and Destinations

The most useful capability of network security groups is that a rule can reference another NSG (or the same NSG) instead of a CIDR block. In a traditional Security List, the source or destination of a rule must be a static CIDR block (e.g., 10.0.1.0/24) or an OCI Service CIDR label.

In contrast, an NSG rule can specify another NSG as its source or destination:

• Application Tier Rule: Ingress rule in DB-Tier-NSG allowing TCP port 1521 where the source is App-Tier-NSG.
• Dynamic Autoscaling: When an autoscaling instance pool launches new application servers, each new VM's VNIC is automatically attached to App-Tier-NSG. The database instances immediately accept connections from the new VM without requiring any manual IP updates or CIDR modifications.
• Zero Hardcoded IPs: Eliminates operational dependencies on static IP assignments and protects against IP address re-use vulnerabilities.

---

Stateful vs. Stateless Filtering & Connection Tracking Limits

Both Security Lists and NSGs allow configuring rules as either Stateful (the default) or Stateless:

Stateful Rules

• Connection Tracking: When a packet matches a stateful ingress rule, the hypervisor's virtual switch records the session in an internal connection tracking table. Return response traffic is automatically permitted, regardless of egress rules.
• Use Cases: Standard web applications, database queries, API services, and general enterprise workloads where bi-directional communication is required.

Stateless Rules

• No Connection Tracking: The hypervisor bypasses the state tracking table entirely. Every packet is evaluated independently. To permit communication, the architect must write explicit matching rules in both directions (ingress and egress), including specifying the client ephemeral port range (typically TCP/UDP ports 32768–65535).
• Use Cases: High-performance computing (HPC), big data streaming (billions of concurrent connections), and DDoS mitigation. Stateless rules eliminate hypervisor state table memory exhaustion and deliver maximum packet-per-second (PPS) throughput with minimum hypervisor latency.

Operational Quotas & Scale Limits

• Security Lists: Up to 5 security lists per subnet and up to 300 per VCN; each security list holds up to 200 ingress and 200 egress rules.
• Network Security Groups: A VNIC can belong to up to 5 NSGs; each NSG holds up to 120 rules (ingress and egress combined). These limits cannot be increased.

---

Defense-in-Depth: Combining Security Lists and NSGs

OCI evaluates Security Lists and NSGs in parallel using a union of permissive rules model. If a packet is allowed by ANY attached Security List rule OR ANY attached NSG rule, the packet is accepted.

Enterprise architectures implement a layered defense-in-depth model:

• Layer 1: Security Lists for Subnet Hygiene: Use a baseline subnet Security List to enforce organization-wide hygiene. Rules allow OCI internal infrastructure traffic (DHCP, OCI DNS resolver on 169.254.169.254:53), administrative bastion SSH from management subnets, and ICMP Type 3 Code 4 (Path MTU Discovery).
• Layer 2: NSGs for Application Micro-Segmentation: Use NSGs attached to specific workload VNICs to restrict business application traffic (e.g., HTTPS port 443, microservice gRPC ports, Oracle SQLNet port 1521).

---

PaaS Private Connectivity: Private Endpoints vs. Service Gateways

By default, OCI Platform-as-a-Service (PaaS) offerings—such as Autonomous Database, OCI Streaming, OCI Analytics Cloud, and OCI Data Integration—reside within the secure Oracle Services Network and present public IP addresses. Enterprise security policies mandate that databases and message brokers never expose public endpoints.

Architects must select between two private access mechanisms:

1. Service Gateway (SGW)

• Mechanics: A virtual gateway on the VCN boundary that routes traffic privately to the Oracle Services Network using Service CIDR labels (e.g., All REGION Services in Oracle Services Network or OCI REGION Object Storage).
• Traffic Flow: Packets remain entirely within Oracle's private network fabric and never traverse the public internet.
• On-Premises Access: On-premises networks connected through a DRG can also reach Oracle services through the VCN's service gateway, a transit routing pattern Oracle calls private access to Oracle services.
• What it does not do: The service still uses its public service endpoint. The service gateway changes the path, not the address, so the service is not placed in your subnet and cannot carry your NSGs.

2. Private Endpoints (PE)

• Mechanics: A Private Endpoint projects the PaaS service directly into a customer-specified private subnet within the VCN. OCI allocates a Virtual Network Interface Card (VNIC) and assigns a genuine private RFC 1918 IP address (e.g., 10.0.3.15) from the subnet to the service.
• Full Transit Routing & Hybrid Access: Because the PaaS resource possesses a native private IP inside the customer subnet, traffic can reach it from:
  • Local compute instances in the VCN.
  • Remote on-premises data centers via FastConnect or IPsec VPN terminated at a DRG v2.
  • Peered VCNs across the region or cross-region via RPC.
• Name Resolution: The service's hostname resolves to the private endpoint IP inside the VCN, so applications keep using the normal TLS connection string. On-premises clients need DNS forwarding to the VCN resolver to resolve the same name.
• NSGs on the endpoint: You can attach NSGs to the private endpoint and allow only specific application tiers. For example, an Autonomous AI Database with a private endpoint can allow port 1522 only from the application NSG.

---

Architectural Comparison: Security & Private Access Mechanisms