Part 5: Network Security

Scenario: Building a demo or proof of concept to understand the technology, azure resources and configuration settings that involve Azure Virtual Networks, VNet Peerings, Virtual Network Gateway, and Site to Site VPN Connections. The architecture is to emulate a hybrid cloud topology with on-premises network emulated with an Azure VNETs in a hub and spoke network topology.

My Azure CLI script to build most of this network architecture can be found at https://github.com/RoyKimYYZ/azurehubandspokenetworkpoc/blob/main/create-hubandspokenetwork.azcli

Network Security

In this design, the the security design considerations and best practices are noted

1. No internet inbound traffic with Network Security Groups.
   The Vnets’ subnets that have local traffic should have Network Security groups (NSG). In my design are the default NSG’s with the following security rules. Even if the subnets don’t have explicit NSG rules, they still have these rules. As you can see the only inbound rule that is allowed is internal VNET traffic within the VNET or peered vnets. For spoke VNets, this allows traffic from the peered hub VNet. Also any Azure Load balancer. But in this design there are no Azure load balancers. There is no explicit inbound internet traffic allowed and as a best practice, one should not enable any.
   

2. Allowing secure inbound internet traffic.
In this design, the VNET gateway in the hub VNet has a public IP address which allows internet traffic. The connection and traffic is secured with secured VPN technology.
The public Azure Load Balancer and Application Gateway can be any entry point for internet traffic for web applications.
Th most recommended to control both ingress and egress traffic is through the Azure Firewall managed service or a VM-based network virtual appliance. User defined routes would be force traffic from subnets to this firewall placed in the Hub VNet. This enabled fine grained network filtering and monitoring.

3. RBAC with VNet management

One should consider role based access with built-in Azure Roles such as network contributor per VNet. This provides security controls on who can add/update and remove azure resources into the respective Net and manage in consistent and organized fashion.

Conclusion

This is my series of my simple approach of a sophisticated topic for those starting out in learning and building out such a design. You can adapt and mold the design in many ways to achieve many fine grained scenarios and security goals.