Application Security groups in SAP on Azure deployments
Published Jul 27 2021 09:33 PM 6,028 Views

Application Security groups in SAP on Azure deployments



In most SAP deployments on Azure, the subscription/VNET segregation happens at the environment level rather than at an SAP application level.  The typical pattern is to have one subscription/VNET per environment like Devtest, pre-prod, prod and DR.   Furthermore, each of these VNETs will be split into multiple subnets like Application subnet, database subnet etc. to achieve  required levels of segregation.  General practice is to use NSGs at the subnet level to filter traffic, however in SAP deployments the list of rules can become huge, complex, and difficult to maintain quickly.  Some common problems with this approach are.


  • You would use huge port ranges across subnets.  This will expose ports on VMs where they may not be required and goes against the Zero trust model Secure networks with Zero Trust | Microsoft Docs
  • Using explicit IP addresses on the NSG rules which is cumbersome to maintain as well as error prone especially if you are using scaling out app servers dynamically.
  • Frequent updates required to the NSG rule which is operationally complex.



Application Security Groups to the rescue


Application security groups enable us to configure network security as a natural extension of an application's structure. We can group VMs based on the application and define network security policies based on those groups. In this way we can achieve  isolation between applications,  introduce zero trust model limiting access to what is required and use easy to remember naming convention which fits our needs instead of listing down hundreds of IP address.


ASG patterns in SAP deployments


Group by SAP application

In this pattern, we create an ASG for each SAP application on corresponding tiers on the DB subnet and one on the application subnet. This pattern gives you most fine-grained control and isolation but requires deep understanding of network traffic patterns in your SAP landscape.


Consider an example SAP landscape with 2 components S/4 HANA and PO as shown below.  Here we have 2 ASGs per application one for the DB VMs and one for the application VMs. NSGs are applied at subnet level using the ASG construct for granular isolation.  






  • On the DB subnet we allow traffic from application VM ASG to the respective DB ASG and deny any other traffic i.e. PO DB will not be accessible from S4HANA application servers and vice versa. 
  • For end users who  access S/4 HANA only, access will be allowed from required source to destination S4HANA App ASG on required ports (32xx, 33xx,36xx,39xx ). They will not be able to access PO using SAPGUI.
  • Similarly for interface traffic coming from non-SAP systems which will only go via PO, access will be allowed from required source to destination PO App ASG on required ports (5xx00, 5xx01 ). They will not be able to access PO using SAPGUI.
  • If we add or remove the number of VMs on the app or DB tier,  the only action required would be to add/remove the NIC  from the respective ASG for the security policy to take effect.
  • Create explicit DenyAll rule on the NSG to override the AllowVNetInBound default security rule.  Using a DenyAll rule would mean that explicit Allow rules would be required  for traffic to flow between VMs of the same SAP component as well as across different SAP components.
  • For management ports like 22/3389 use JIT VM access.


Group by Application type

In this pattern, we create ASGs by application type i.e. one for ABAP based systems, one for Java based systems etc. Similarly on the database we create groups by DB types like DB2, HANA, SQL server etc.  Though this doesn’t give you the level of control above option offers it still ensures that we open only required set of ports on the VMs which it is listening on and not everything.  


Consider same example of above with 2 components S4HANA and PO, assume PO is running on DB2.





Another possible pattern is to group SAP applications by their criticality and compliance requirements. Note that VM can be part of multiple ASGs and each NSG rule can have multiple ASGs assigned as the source or target so combination of the above approaches is also possible.  Refer link for limits



Common traffic types in SAP landscapes

Below are some of the common traffic types typically seen in SAP landscapes which needs to be considered when formulating a strategy for ASG setup.


  • End user (business user)  access to SAP systems. This can be through thick clients like SAPGUI or web based or mobile apps.
  • Technical users (SAP Basis teams, SAP functional teams) accessing SAP systems for Operational purposes.
  • Communication between SAP application cluster nodes like database HA nodes, ASCS/ERS cluster, message server to app server traffic.
  • Communication between different SAP components within the same environment using RFCs.
  • Communication across environments i.e. Non-prod to prod for change movement using transports and solution manager monitoring data
  • Non-SAP systems communicating with SAP system for interfaces.
  • Data replication/ingestion from SAP to other data sources like data lake.
  • SSH/RDP to SAP VMs for administration (highly recommend JIT for this). 



Steps to create NSG rules using ASG


Below are the high-level steps to setup rules as described in the architecture above.  For detailed step by step guidance on setting up NSG with ASGs refer to


  • Create the required ASGs. This can be done either from Azure Portal or PS or Azure CLI command line options



  • Create network security rules on the respective app and DB subnet NSGs using the ASGs created above. Below is an example of rule on the NSG associated with database subnet to allow inbound traffic from app to db. Similarly create rules for app-to-app communication, end user to app communication and communication between HA nodes on each tier.





  • Create a Deny all rule with highest prioritykvenkat_42-1627404971404.png
  • Associate the VM NICs to the appropriate ASGs for the security rules to take effect. (single NIC to multiple ASGs if required).





To conclude, Application Security groups is highly recommended in SAP deployments from perspective of having tight security controls as well as  reducing operational complexity of maintaining IP addresses or ranges on NSG rules.  


Version history
Last update:
‎Nov 18 2021 02:32 PM
Updated by: