SAP RISE, a fully managed service for SAP landscapes, offers a streamlined path to the cloud. However, to fully leverage its potential, integration with Azure services is essential. This integration enhances functionality, security, and overall operational efficiency for organizations running SAP workloads. By combining the strengths of SAP RISE with the breadth of Azure’s services, businesses can create a robust and agile IT environment. This post explores the key aspects of integrating SAP RISE with Azure, emphasizing the benefits and practical steps involved and how this approach helps to optimize and secure your SAP landscape. A crucial element to understand when integrating SAP RISE with Azure is the shared responsibility model; SAP manages the RISE infrastructure, and the customer manages the applications and integrations.
Key Takeaways
SAP RISE Azure integration provides enhanced functionality and security for your SAP landscape.
Microsoft Entra ID is a key component for SSO and IAM, replacing SAP IDM and streamlining user management.
Microsoft Sentinel and Copilot for Security are indispensable for advanced threat detection and response, improving your security posture.
Various network options are available, with virtual network peering being the most performant for most scenarios.
Data and application integration can be achieved using self-hosted integration runtimes and on-premises data gateways, enabling data driven analytics and app development.
The shared responsibility model means you are responsible for the resources in your own Azure subscription.
DNS integration is essential to maintain a seamless environment.
Internet connectivity is not enabled by default and requires planning with SAP for the required configurations.
SAP Private Link Service allows private connections to SAP BTP, improving security and performance.
Table of Content
Single Sign-On (SSO) Configuration
Single sign-on (SSO) is a fundamental requirement for any enterprise environment, ensuring seamless access to applications while maintaining security. For SAP RISE Azure environments, implementing SSO is no different from natively run SAP systems. The primary goal is to simplify the user authentication process, allowing users to access SAP applications using their existing credentials, typically managed through Microsoft Entra ID.
There are several ways to configure SSO for SAP RISE, SAML/OAuth
This method is commonly used for SAP Fiori, Web GUI, Portal, and HANA. Configuration is typically done by the customer within their Azure subscription, linking the SAP environment to Microsoft Entra ID.
SNC (Secure Network Communications)
This is predominantly used for SAP GUI connections. It also integrates with Microsoft Entra ID but requires the use of the SAP SSO Secure Login Client.
SPNEGO
This method integrates with Active Directory (AD) and is used for Web GUI and SAP Enterprise Portal.
For SAP GUI connections, integration with the customer’s Active Directory (AD) is usually necessary, particularly for end-user devices. However, with SAP RISE, Windows systems are not directly integrated with the customer's Active Directory domain. Instead, the domain security token is securely read from the client device. If you need changes to integrate AD-based SSO or are using a third-party product other than SAP SSO Secure Login Client, you should contact SAP because configuration on the RISE-managed system may be required.
Identity and Access Management (IAM)
Effective Identity and Access Management (IAM) is critical for maintaining a secure and compliant SAP environment. SAP has announced the retirement of SAP Identity Management (SAP IDM) by 2027, recommending customers migrate to Microsoft Entra ID. Microsoft Entra ID Governance offers a comprehensive solution for managing the SAP user lifecycle and authorizations across both the SAP and Microsoft ecosystems. The built-in integrations with SAP Cloud Identity Service make it an ideal choice for managing identities, access, and governance within your SAP RISE Azure landscape.
Enhancing Security with Microsoft Copilot for Security
In today’s complex threat landscape, proactive security measures are essential. Microsoft Copilot for Security is a generative AI security product that empowers security and IT professionals to respond to cyber threats effectively. Copilot for Security can analyze and process security signals and assess risk exposure at an unprecedented speed and scale. Copilot for Security has its own portal and embedded experiences in Microsoft Defender XDR, Microsoft Sentinel, and Intune.

Here’s how it can be used with SAP RISE/ECS:
Threat Investigation
You can use Copilot for Security to investigate SAP-related incidents, processing data from various sources.
Remediation
Copilot for Security provides recommendations and remediation actions, like password resets for SAP systems, directly through Microsoft Defender XDR.
Integration
Copilot for Security is integrated within the Microsoft Defender XDR portal, leveraging data ingested through Microsoft Sentinel for SAP applications.
Monitoring and Threat Detection with Microsoft Sentinel
Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) solution. The Microsoft Sentinel solution for SAP applications allows you to monitor, detect, and respond to suspicious activities within your SAP RISE environment. Microsoft Sentinel guards your data against sophisticated cyberattacks, whether your SAP systems are hosted on Azure, other clouds, or on-premises infrastructure.
Key capabilities of Microsoft Sentinel with SAP RISE
Centralized Monitoring
Use a single console to monitor your entire enterprise, including SAP instances in SAP RISE/ECS, on Azure, or on-premises.
Threat Detection
Detect and automatically respond to threats such as privilege escalation, unauthorized changes, sensitive transactions, and data exfiltration using out-of-the-box detection capabilities.
Cross-Correlation
Correlate SAP activity with signals from other sources, such as endpoints and Microsoft Entra data, to more accurately detect threats.
Customization
Build your own detections to monitor sensitive transactions and other business risks.
Data Visualization: Visualize data using built-in workbooks
The Microsoft Sentinel solution must be deployed within the customer's Azure subscription. The solution does not require installations on the SAP systems, but an authorized RFC user for connectivity is needed. Data collection is done using a container-based SAP data collection agent that you can install on a VM, AKS, or any Kubernetes environment. This agent uses an SAP service user to consume application log data through the RFC interface. Supported authentication methods are SAP username and password or X509/SNC certificates. Note that only RFC based connections are currently supported with SAP RISE/ECS environments.
An important requirement is importing an SAP transport change request for specific log fields, such as client IP address information, DB table logs, and spool output logs. While Sentinel’s built-in content provides coverage even without these log sources, it enhances detection capabilities. It is also important to note that SAP infrastructure and operating system logs are not available to Sentinel in RISE due to the shared responsibility model.
Microsoft Sentinel also has SOAR capabilities that allow you to automate responses to threats. Pre-built playbooks can be used for actions such as blocking suspicious SAP users, with options for intervention from Microsoft Teams. This integration can be applied to any incident type, spanning across SAP BTP or Microsoft Entra ID.
Data Integration with Azure Services
Integrating your SAP RISE Azure environment with Azure data services like Azure Data Factory and Azure Synapse Analytics is crucial for leveraging SAP data for advanced analytics and reporting. This involves setting up communication channels between your SAP system and Azure services.
You can use either a self-hosted integration runtime (IR) or an Azure integration runtime. Most SAP connectors are only available for the self-hosted IR. The choice of IR affects the network path taken for data transfer.

Self-Hosted Integration Runtime
The self-hosted IR communicates with the SAP system within the SAP RISE/ECS subscription via the established vnet peering and private network address. You are responsible for deploying and operating the self-hosted IR within your Azure subscription.
Azure Integration Runtime
The Azure integration runtime accesses your SAP environment through a public IP address, with communication secured via HTTPS. SAP RISE/ECS provides the endpoint via an application gateway.
For self-hosted IR, the connection between Azure PaaS services and the integration runtime is within your Azure subscription. SAP RISE/ECS exposes the communication ports but does not manage any details of the connected application or service.
Application Integration with On-Premises Data Gateway
For application integration, Azure services like Azure Logic Apps, Power Apps, and Power BI communicate with SAP systems via an on-premises data gateway. This gateway is a virtual machine that can be deployed in Azure or on-premises and provides secure data transfer. With SAP RISE Azure, the on-premises data gateway connects to Azure integration Services within your Azure subscription. You are responsible for deploying and operating this VM.
The on-premises data gateway VM uses the SAP .NET connector to run RFC, BAPI, or IDOC calls through the RFC connection. Depending on the service and setup, a connection to the public IP of the SAP systems’ REST API via HTTPS may also be required. The communication ports are accessed through the private network address using vnet peering or VPN connections.
SAP RISE/ECS exposes the necessary communication ports but does not have any knowledge of the connected application or service running in your Azure subscription.
Network Connectivity Options
Secure and performant network connectivity is the backbone of successful SAP RISE Azure integration. SAP RISE operates within a separate virtual network, and establishing connectivity with your own Azure environment is essential.
There are several options available,
Virtual Network Peering

This is the preferred and most performant method. Vnet peering creates a direct, private connection between virtual networks, enabling applications to communicate with low latency and high throughput. It also avoids traversing the internet. For SAP RISE/ECS, you must set up peering between different tenants since SAP RISE runs in SAP’s Azure tenant and subscriptions.
VPN vnet-to-vnet

As an alternative to vnet peering, you can establish a VPN connection between VPN gateways deployed in both the SAP RISE/ECS subscription and your own. While this is an option, it is generally less preferred because vnet peering has better performance.
Connectivity to On-Premises

Existing on-premises networks are typically connected to Azure via ExpressRoute (ER) or VPN, and these paths can be used for SAP RISE/ECS workloads. The SAP RISE virtual network is seen as a spoke network connected to your virtual network hub.
Azure Virtual WAN (vWAN)
vWAN can be used as a hub, with SAP RISE being a spoke network, offering another option for connecting your SAP environment.
It is crucial to secure communication between your network and SAP RISE via Network Security Groups. For a globally distributed SAP landscape, it is recommended to use a multi-region network architecture with SAP RISE peering locally in each geography.
DNS Integration
Seamless DNS resolution is vital for a successful integration. In a typical setup, your Azure hub or on-premises DNS servers hold all DNS entries. The DNS infrastructure should be able to resolve DNS requests from all sources, including on-premises clients, your Azure services, and the SAP-managed environments.

Here’s how DNS is integrated:
Custom DNS Configuration
SAP-owned virtual networks hosting the RISE/PCE environment use custom DNS configurations. SAP provides and delegates a subdomain for DNS entries (e.g., ecs.contoso.com).
DNS Zone Transfer
The primary method to replicate DNS entries from the RISE/PCE environment to your DNS servers is through DNS zone transfer.
Private DNS Forwarder
Optionally, you can set up a private DNS forwarder within your Azure virtual networks, pushing DNS requests to the SAP DNS servers for the delegated zone.
It’s important to note that Azure DNS and private zones do not support DNS zone transfers and, therefore, cannot be used to accept DNS replication from SAP RISE/PCE/ECS DNS servers.
Internet Connectivity
By default, network communication to and from the internet is not enabled for SAP RISE/ECS customers, as default networking uses private IP ranges only. If your SAP workloads need to communicate with external applications or interfaces, or if your users need inbound connections, you will need to work with your SAP representative to enable the needed communication paths. Network communication to and from the internet is typically contained within the SAP RISE/ECS virtual network and does not pass through the customer’s vnet. This connection is protected using various Azure services, such as NSGs, ASGs, and Application Gateway with Web Application Firewall (WAF).
SAP BTP Connectivity
SAP Business Technology Platform (BTP) is accessed through public IPs, and your services within your Azure subscription can connect through the configured outbound access methods, such as a central firewall. For services like SAP Data Intelligence, access is through a separate virtual network peering rather than public endpoints.
SAP offers Private Link Service for customers using SAP BTP on Azure, enabling private access from BTP using a private IP range.
Conclusion
The integration of SAP RISE with Azure offers significant enhancements in functionality and security1. Key components like Microsoft Entra ID, Microsoft Sentinel, and Copilot for Security improve user management and threat detection1. Various network options, especially virtual network peering, provide high-performance solutions1. Furthermore, data and application integration is achievable through self-hosted integration runtimes and on-premises data gateways1. However, it's crucial to understand the shared responsibility model, ensure proper DNS integration, plan for internet connectivity, and leverage the SAP Private Link Service to maximize the benefits.
Comentários