All about Application Security Group

What is Application Security Groups?

ASGs enable you to define fine-grained network security policies based on workloads, centralized on applications, instead of explicit IP addresses. Implementing granular security traffic controls improves isolation of workloads and protects them individually. If a breach occurs, this technique limits the potential impact of lateral exploration of your networks from hackers.

You may find the details in the MS site more about this which I do not want to copy and paste it here. Let’s talk about the use case and how we can make use of his in better way.

Deny all the communication and open the specific communication using ASG. Yes, you can create a Deny All rule with lower priority within your vNET. Then you create specific ports to open but you will select ASG as source and destination. This will open the communication between those servers have the specific ASG configured. Looks at the below pictures (figure1&2) to understand this better.

You do not have any option to add a server in the ASG but you need to go and select the required ASG from the vNIC of the VMs. You can add this option in the ARM templates to configure when you create this VM. This will reduce number NSG changes you need to make every time you add a server rather you select required ASG while you create the VM.

You need to remember few things about ASG.

• You cannot make any settings on ASG but you can only add tags.
• You can only select one ASG as source or destination in every NSG rules.
• You can select multiple ASGs for single VM.
• Limitations
  • 3000 per subscription
  • 20 per vNIC
  • 4000 IP configuration per ASG
• You can only assign ASG from the same subscription.
• You cannot have VMs from different vNETs in one ASG.
• Both source and destination ASGs in your NSG rules should be in same vNET.

Benefits.

• It reduces need to for creating or updating NSG every time you add a server to existing application set.
• Allow point to point communication with less number of NSG rules.

 

Let’s take look at some design scenarios. You have vNET with 3 tier application which is behind an application gateway.

Figure 1

 

• 4x subnets
  • Application Gateway subnet – 10.0.0.64/28
  • Web subnet – 10.0.0.80/28
  • App subnet – 10.0.0.96/28
  • DB subnet – 10.0.0.112/28
• Apps 3x
  • Web1-App1-DB1
  • Web2-App2-DB2
  • Web3-App3-DB3

Scenario:

• Application Gateway should only communicate to Web tier
• Web1 should only communicate to App1 but not DB1
• App1 should only communicate to DB1
• Web, App and DB in one application should not communicate with other application set.

What is required.

Figure 2

• Application Security Group. 9x ASG
  • Web1ASG, App1ASG, DB1ASG
  • Web2ASG, App2ASG, DB2ASG
  • Web3ASG, App3ASG, DB3ASG
• NSG rules – x should be replaced with 1 or 2 or 3.
  • NSG Web
    • Deny Inbound Rules
      • Source: 10.0.0.0/24
      • Destination: 10.0.0.0/24
      • Port: Any
      • Protocol: Any

You can selectively deny both TCP and UDP to allow ICMP. NSG does not have an option to selectively allow this.

• NSG Web
  • Allow Inbound Rules (from AppGW to Web Server)
    • Source: 10.0.0.64/28
    • Destination: Webx ASG
    • Port: xxx
    • Protocol: xxx
• NSG App
  • Allow Inbound Rules (from Web to App Server)
    • Source: Webx ASG
    • Destination: App x ASG
    • Port: xxx
    • Protocol: xxx
• NSG DB
  • Deny Inbound Rules
    • Source: Appx ASG
    • Destination: DBx ASG
    • Port: xxx
    • Protocol: xxx
  • Add ASGs to VMs
    • We need to add respective ASG to the each VM.
      • Webx (VM) – WebxASG
      • Appx(VM)-AppxASG
      • DBx(VM) – DBxASG

 Figure 3

I think it is good to have an option to list the number of VMs mapped to a NSG which is currently does not existing. I suggest MS to consider this in next release.

Reference:

https://azure.microsoft.com/en-in/blog/applicationsecuritygroups/

Please provide your comments if there are any corrections required.