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.
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 i.e.one 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.
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 https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-...
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.
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 https://docs.microsoft.com/en-us/azure/virtual-network/tutorial-filter-network-traffic#create-a-netw...
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.