Microsegementation with Network Security Groups

OCI Network Security Group rules function the same as Security List rules. But, you can specify another Network Security Group (NSG) as the rule's source or destination address instead of an IP CIDR. You can easily write security rules to control traffic between NSGs within a VCN. This allows for microsegementation between different application functions.

For example, a public-facing web service with backend app servers and a database. The public web server needs to allow inbound HTTP requests from external clients while the database needs additional security. Allowing access from specific app servers performing database queries generated by web clients searching a product catalog on the website. Rather than allowing an entire network or subnet access to the database, limit communication to specific resources by assigning them to a NSG.

View the companion video for this blog, which shows the entire demo on microsegementation with NSGs:

Use Case

Let's review an example based on the use case mentioned above. We’ll use a multi-tier design with one VCN and three separate subnets. Each subnet is its own tier. We’ll use network security groups, also known as NSGs to provide microsegmentation between the Web, App, and Database tiers. 

• The Web NSG allows HTTP traffic from any IP address, including the Internet.
• The App NSG will only accept traffic over TCP port 8080 from resources assigned to the Web NSG.
• The DB NSG will only allow SQL access to resources assigned to the App NSG.

Note: VNICs are assigned to NSGs, not IP networks or IP addresses.

Looking in the OCI Console we have three NSGs named Web, App, & DB. Each NSG will be associated to a VNIC within its designated subnet. Going through each NSG notice the slight differences in each NSG security configuration.

Web NSG: The security rule allows incoming traffic from any IP address (0.0.0.0/0) over port 80. Any VNIC assigned to this NSG will allow this particular access:

App NSG: Notice the Source or Destination column this security rule allows traffic to the custom TCP port 8080 from resources assigned to the Web NSG:

DB NSG: Again take a look at the Source or Destination column the security rule will accept incoming SQL traffic only from resources assigned to the App NSG:

The left VNIC menu in the NSG section allows you to view which VNICs are currently assigned to the NSG. I've attached the App instance located in the App Tier to the App NSG:

I've also attached the Private Endpoint in the Database Tier to the DB NSG. Instead of the instance name in the VNIC menu, we see the OCID associated with the Autonomous Database (ADB) Private Endpoint:

Notice that the Web NSG currently has no VNICs assigned: 

If I attempt to access the Web VM it will time out (as shown in the companion video) due to missing security rules. Remember OCI Security Lists and NSGs uses an implicit deny policy. Only rules added to the Security List or NSG will allow the specified traffic.

To fix this issue I've assigned my Web instance VNIC to the Web NSG, once assigned I'm now able to access the website:

Note that the Web instance now appears in the Web NSG VNIC menu:

Recall the App NSG only allows connectivity from resources assigned to the Web NSG. Additional testing shows that the Web Instance can access the App Instance over TCP 8080 now that it's  attached to the Web NSG.

Since the App instance VNIC is attached to the App NSG it has SQL (Port 1521) access to the Autonomous Database. Remember the DB NSG only allows SQL connectivity from resources assigned to the App NSG.

Conclusion

In this blog, we tested access to and from network security groups using a multi-tier architecture. Segmenting network traffic by application access needs. As you build out your VCN architecture take advantage of the flexibility NSGs provide. Such as assigning instances with different security postures in the same subnet with unrelated NSGs.

To learn more about NSGs please read our official OCI documents located here.