Enhancing Security in OCI: Using Network Security Groups with HeatWave MySQL

Security is a foundational principle for cloud deployments, especially when dealing with mission-critical workloads like those managed by HeatWave MySQL. As applications and environments scale, fine-grained network control becomes critical not just for protecting sensitive data, but also for isolating systems, enforcing boundaries, and minimizing lateral movement within a Virtual Cloud Network (VCN).

Network Security Groups (NSGs) enable microsegmentation a security architecture that allows you to apply stateful, virtual firewall rules at the VNIC level, rather than only relying on subnet-level security lists. For customers using HeatWave MySQL on OCI, NSGs now offer tighter control of database access from approved application compute instances, load balancers, or other cloud-native components.

In this blog, we’ll walk through how to use NSGs to secure HeatWave MySQL DB systems, how it compares to security lists, and how to configure the necessary policies and rules for a secure, scalable setup.

Why Microsegmentation Matters for HeatWave MySQL

In many customer environments, multiple workloads coexist within the same VCN. You might have:

A web tier deployed on OCI Compute Instances
A backend tier powered by HeatWave MySQL
Additional third-party tools or testing utilities in dev/test environments

Without microsegmentation, you may resort to broad security lists that allow too much traffic within the subnet. This increases the attack surface and makes it difficult to audit or restrict access.

With NSGs, you can enforce precise network paths. Only the application Compute instance (e.g., App-1) can communicate to database (e.g, DB-1). No other compute or container even on the same subnet can access DB-1 unless explicitly allowed.

NSG with HeatWave MySQL

NSGs are supported for both primary DB systems and their Read Replicas (RR)
Each DB system or Read Replica can be associated with up to 5 NSGs
NSGs are tied to the customer-managed VNICs of the selected DB systems or Read Replicas. Any traffic to the database will be filtered based on the rules defined in those NSGs
For DB systems with a Read Replica, the private endpoint of the Replica’s Network Load Balancer (NLB) will honor the NSG configuration applied to the DB system

Here’s a sample architecture:

App-VM-1 runs in nsg-app-dev
HeatWave MySQL DB System (DB-1) runs in nsg-db-dev
Both are in the same VCN and subnet
Security Lists allow basic egress/ingress (or minimal/default rules)
NSGs control the actual traffic flow

Traffic Flow Example:

Source	Destination	Protocol	Port	Rule Location
App-VM-1	HeatWave DB Systems	TCP	3306	NSG Ingress

NSG Configuration Steps

Here are the four steps you’ll need to follow to get your NSG setup working smoothly.

Step 1: Create Two NSGs

nsg-app-dev – for your Compute instance
nsg-db-dev – for your HeatWave MySQL DB System

Figure 1: NSG creation showing nsg-app-dev and nsg-db-dev

Step 2: Attach NSGs to Resources

For Compute, edit the VNIC to attach nsg-app-dev

Figure 2: Compute instance showing nsg-app-dev attached

When provisioning the DB System, assign nsg-db-dev

Figure 3: HeatWave MySQL DB system showing nsg-db-dev attached

Step 3: Add NSG Rules

Egress Rule for nsg-app-dev

Source Type: Network Security Group
Source: nsg-db-dev
Protocol: TCP
Destination Port: 3306
Stateless: No

Ingress Rule for nsg-db-dev

Source Type: Network Security Group
Source: nsg-app-dev
Protocol: TCP
Destination Port: 3306
Stateless: No

This ensures only traffic from nsg-app-dev can reach the HeatWave DB on port 3306.

Step 4: IAM Policies

To allow the HeatWave DB System to interact with NSGs and VNICs securely, the following IAM policies must be set:

Allow HeatWave MySQL to update NSG membership

Allow any-user to {NETWORK_SECURITY_GROUP_UPDATE_MEMBERS} in compartment <NSG_compartment_name>
      where all {request.principal.type='mysqldbsystem', request.resource.compartment.id='<DBsystem_compartment_OCID>'
    }

Allow VNIC operations required by HeatWave MySQL

Allow any-user to {
      VNIC_CREATE,
      VNIC_UPDATE,
      VNIC_ASSOCIATE_NETWORK_SECURITY_GROUP,
      VNIC_DISASSOCIATE_NETWORK_SECURITY_GROUP
    } in compartment <subnet_compartment_name> 
      where all {request.principal.type='mysqldbsystem', request.resource.compartment.id='<DBsystem_compartment_OCID>'
    }

Replace <NSG_compartment_name>, <subnet_compartment_name>, and <DBsystem_compartment_OCID> with actual OCIDs from your setup.

Tip: NSGs and Security Lists Work Together

When using both NSGs and Security Lists, the union of both rule sets is enforced.

This means that a packet is allowed if either the NSG or the security list allows it. For example:

Your Security List allows SSH from 0.0.0.0/0
Your NSG does not allow SSH
SSH is still allowed because the Security List permits it.

To avoid unintended access:

Minimize or eliminate Security List rules for subnets using NSGs
Rely on NSGs for workload-specific access control

Test Case: Dev Isolation with NSGs

Imagine:

Compute-Dev-1 → DB-Dev-1 (Security List-based access)
Compute-Dev-2 → DB-Dev-2 (NSG-based access)

If all are in the same VCN, Compute-Dev-1 can connect to DB-Dev-2 if the subnet security list allows it, regardless of NSG rules.

To fix this:

Lock down the subnet security list to only required traffic
Use NSGs for precise application-to-database traffic paths

Conclusion

Adopting NSGs with HeatWave MySQL in Oracle Cloud Infrastructure enables fine-grained, workload-level network security. By moving away from subnet-level security lists and embracing NSG-based microsegmentation, you can enforce stronger isolation, reduce blast radius, and support zero-trust architecture patterns within your cloud estate.

Whether you’re operating a secure production workload or isolating environments during development, NSGs are the right tool to achieve flexible, auditable, and secure access control for your HeatWave MySQL DB Systems.

Enhancing Security in OCI: Using Network Security Groups with HeatWave MySQL