Identity and Security with RISE

Identity and Security with SAP RISE on Azure

Introduction: The Security Landscape of SAP RISE

When organizations decide to move their SAP workloads to the cloud via the SAP RISE program, they are essentially entering a shared responsibility model. SAP RISE is a managed service offering where SAP takes on the responsibility of managing the underlying infrastructure, the operating system, and the SAP application layer. However, the security of your identity, access, and data remains firmly in your hands as the customer. Understanding this division is the most critical step in ensuring that your enterprise resource planning (ERP) environment does not become a vulnerability.

Identity and security in this context are not merely about setting up passwords or firewall rules. It is about establishing a cohesive governance framework that spans your on-premises identity providers, the Azure cloud environment, and the SAP application itself. Because SAP RISE environments are often interconnected with other business-critical systems, a failure in identity management can lead to unauthorized data access, compliance violations, or even operational downtime. This lesson will guide you through the technical architecture, best practices, and configuration steps required to secure your RISE environment effectively.

Understanding the Shared Responsibility Model

Before diving into configurations, we must clearly define what we mean by "shared responsibility." In a traditional on-premises data center, you are responsible for everything from the physical hardware in the rack to the application patches. Under SAP RISE on Azure, that spectrum shifts significantly.

SAP manages the hardware, the virtualization layer, the OS, and the SAP application patches. You, as the customer, maintain control over the identity lifecycle, the network access policies, and the configuration of the data itself. If a user account is compromised because of poor password hygiene or a lack of multi-factor authentication, that is a customer-side issue. If the underlying server hardware fails, that is an SAP-managed issue.

Callout: The Identity Perimeter In the modern cloud era, the identity has become the new perimeter. Unlike traditional network-based security where "inside the wall" meant "trusted," cloud security assumes that the network can be accessed from anywhere. Therefore, the identity of the user, the health of the device they are using, and the context of their request (such as location and time) are the primary factors that determine whether access should be granted.

Identity Federation with Microsoft Entra ID

The cornerstone of modern identity management in Azure is Microsoft Entra ID (formerly Azure Active Directory). For SAP RISE customers, the goal is to create a unified identity experience where users use their existing corporate credentials to access the SAP environment. This is achieved through federation.

Federation allows your local identity provider (like an on-premises Active Directory or a third-party provider) to "talk" to Microsoft Entra ID. When a user tries to log into an SAP application hosted in RISE, the application redirects the user to Entra ID. If the user is already signed in elsewhere, or if they provide their credentials, Entra ID issues a token that the SAP application trusts.

Configuring SAML 2.0 for SAP Applications

Most SAP applications in the RISE environment support SAML 2.0 for Single Sign-On (SSO). The setup involves establishing a "trust relationship" between the SAP system (the Service Provider) and Microsoft Entra ID (the Identity Provider).

1. Register the SAP App in Entra ID: Navigate to the Enterprise Applications section in the Azure portal. Create a new application and select the "SAP" template if available, or a generic SAML application.
2. Metadata Exchange: Download the Federation Metadata XML from the Entra ID application settings. You will need to upload this into the SAP system using transaction code SAML2.
3. Configure the Service Provider: In the SAP SAML2 transaction, you must define the local provider name and upload the metadata file you just received from Azure.
4. Attribute Mapping: You must ensure that the user identifier in Entra ID (usually the User Principal Name or Email) matches the user ID in the SAP system (the BNAME field). If these do not match, the authentication will fail.

Tip: User Mapping Consistency Always ensure that your user provisioning process is automated. If you manually create users in SAP and rely on email-based SSO, you will eventually face a "broken link" where an employee changes their email address or leaves the company, but the SAP account remains active. Use tools like SAP Identity Management (IDM) or SCIM-based provisioning to automate this lifecycle.

Securing Network Access: BGP, ExpressRoute, and Private Links

While identity handles who gets in, network security handles how they get there. SAP RISE environments on Azure are typically connected to your corporate network via ExpressRoute. This provides a private, dedicated connection that does not traverse the public internet.

However, a private connection does not mean you can ignore security. You must implement "Zero Trust" principles even within your private network. This means that just because a packet originates from your corporate office, it shouldn't automatically be granted full access to the SAP database or application server.

Implementing Network Security Groups (NSGs)

NSGs act as virtual firewalls. In an SAP RISE on Azure setup, you have specific subnets for application servers, database servers, and management traffic. You should configure your NSG rules to follow the principle of least privilege:

• Restrict SSH/RDP: Never expose port 22 or 3389 to the entire corporate network. Use a Just-In-Time (JIT) access mechanism or a bastion host.
• Database Isolation: The SAP database server should only accept connections from the application server subnet, not from general user workstations.
• Outbound Traffic: Limit outbound traffic from your SAP servers to only the necessary Azure services (like Azure Monitor or backup services).

The Role of SAP Cloud Identity Services

SAP provides its own identity layer, known as SAP Cloud Identity Services (SCI), which acts as a bridge between your corporate identity provider and the SAP ecosystem. For many RISE customers, the architecture looks like this:

1. User Identity: Stored in Microsoft Entra ID.
2. Identity Bridge: SAP Cloud Identity Services acts as a proxy.
3. Target System: The SAP RISE environment (S/4HANA, etc.).

This architecture is highly recommended because it decouples your corporate identity changes from the SAP application configuration. If you change your corporate identity provider, you only update the bridge, not every individual SAP system.

Comparison: Direct Federation vs. SAP Cloud Identity Services

Warning: Hardcoding Credentials Never hardcode service account credentials into your integration scripts or configuration files. If you find yourself needing a password for a scheduled job or an API call, use Azure Key Vault to store the secret and grant the SAP server's managed identity the permission to retrieve it. This ensures that you can rotate keys without touching the application code.

Advanced Security: Conditional Access Policies

Conditional Access is perhaps the most powerful tool in the Microsoft Entra ID arsenal for protecting SAP RISE. It allows you to define "if-then" statements that govern access. For example: "If a user is accessing the SAP environment from an unknown location, then require Multi-Factor Authentication."

Designing Conditional Access for SAP

When designing policies for your SAP environment, consider these three pillars:

1. User Risk: Use Entra ID Identity Protection to identify compromised credentials. If the system detects a user's password on the dark web, you can automatically block their access to SAP.
2. Device Compliance: Require that the device used to access SAP is managed by your organization (e.g., Intune-enrolled). This prevents users from logging into sensitive ERP data from personal, unmanaged tablets or phones.
3. Location Awareness: If your company only operates in specific countries, you can block access to the SAP RISE environment from all other countries. This is an effective way to stop brute-force attacks from international sources.

Example: Implementing a Strict Policy

To implement a policy requiring MFA for all SAP access:

1. Log into the Azure Portal and go to Microsoft Entra ID.
2. Select Security > Conditional Access.
3. Create a new policy named "Require MFA for SAP RISE".
4. Assign the policy to all users or a specific group (e.g., "SAP Users").
5. Under Cloud apps or actions, select the specific SAP Enterprise Application you registered earlier.
6. Under Grant, select Grant access and check the box for Require multi-factor authentication.
7. Enable the policy in "Report-only" mode first to test for a week before enforcing.

Managing SAP RISE Security Logs

Security is not a "set it and forget it" task. You must have visibility into what is happening within your environment. SAP RISE on Azure provides integration with Azure Monitor and Microsoft Sentinel.

Azure Monitor and Log Analytics

You should stream your SAP application logs and Azure infrastructure logs into a centralized Log Analytics Workspace. This allows you to run Kusto Query Language (KQL) queries to detect anomalies.

Example KQL Query for Failed Logins:

SigninLogs
| where AppDisplayName == "SAP-RISE-Production"
| where ResultType != 0
| summarize count() by UserPrincipalName, IPAddress, bin(TimeGenerated, 1h)
| where count_ > 5

This query identifies users who have failed to log into the SAP application more than five times in an hour, which could indicate a password-spraying attack.

Microsoft Sentinel

For larger organizations, Microsoft Sentinel (a SIEM/SOAR solution) is the industry standard. It can ingest your SAP logs and correlate them with other events in your network. For instance, if a user downloads a massive amount of data from the SAP system and simultaneously logs into a different internal resource from an unusual IP, Sentinel can automatically trigger a lockout of the account.

Best Practices for Ongoing Security

Maintaining a secure SAP RISE environment requires a culture of continuous improvement. Below are the industry-standard practices for long-term security.

1. The Principle of Least Privilege (PoLP)

Do not give users the "SAP_ALL" profile. In an ERP system, this is equivalent to giving a user domain admin rights. Use the role-based access control (RBAC) features in SAP to define exactly what tasks a user needs to perform. Audit these roles quarterly to remove unused permissions.

2. Regular Patching Cadence

While SAP handles the OS and application patching in a RISE environment, you must participate in the planning. Ensure you are aware of the SAP Security Notes (the "HotNews" alerts) that are released on the second Tuesday of every month. Collaborate with your SAP RISE service delivery manager to ensure these patches are applied within your maintenance windows.

3. Data Encryption

Ensure that all data is encrypted both at rest and in transit. Azure handles the disk encryption (using Azure Disk Encryption or managed keys), but you must ensure that your connections to the SAP application are forced over HTTPS/TLS 1.2 or higher.

Callout: Encryption vs. Access Remember that encryption protects you if a physical disk is stolen or an unauthorized person gains access to the storage account. It does not protect you if a user logs into the application with a compromised password. Encryption is the "last line of defense," whereas identity management is the "first line of defense."

4. Incident Response Planning

What happens if you suspect an SAP breach? You need a documented incident response plan that specifically mentions the SAP RISE service desk. You must know exactly how to escalate a security incident to SAP so they can isolate the environment or provide the necessary logs for forensic analysis.

Common Pitfalls and How to Avoid Them

Even with the best intentions, organizations often fall into common traps when securing their SAP RISE landscape. Here are the most frequent mistakes:

• The "Shadow IT" Trap: Departments often spin up small SAP instances or integrations without informing the central IT security team. This creates blind spots. Solution: Enforce a centralized governance policy where all SAP workloads must be deployed through the approved Azure Landing Zone.
• Ignoring the SAP-to-Azure Bridge: Often, security teams focus on the Azure side and ignore the SAP-specific security configurations (like the SAML2 setup or the RFC connections). Solution: Ensure that your security audit process covers both the Azure configuration and the SAP transaction-level security.
• Over-reliance on Network Security: Some teams believe that because they have an ExpressRoute, they don't need to worry about application-layer security. Solution: Always assume the network is compromised. Use application-level authentication and authorization as your primary defense.
• Poor Service Account Management: Service accounts are the "keys to the kingdom." If one is compromised, it often has high-level permissions. Solution: Use Managed Identities where possible. If you must use a service account, rotate its password frequently and restrict its scope to only the specific SAP system it needs to access.

Step-by-Step Security Review Checklist

If you are currently managing an SAP RISE on Azure environment, use this checklist to perform a quick security health check:

1. Identity: Are all users accessing SAP via Entra ID with MFA enabled?
2. Network: Are there any open ports (other than 443/80) exposed to the public internet?
3. Governance: Have you performed a review of "SAP_ALL" and other administrative profiles in the last 90 days?
4. Logging: Are your logs being sent to a centralized Azure Log Analytics workspace?
5. Alerting: Do you have an alert set up for high-severity security events in your SAP environment?
6. Key Management: Are your integration secrets stored in Azure Key Vault rather than local configuration files?

Key Takeaways

As we conclude this lesson, remember that security is a process, not a destination. By leveraging the integration between SAP RISE and the Azure security ecosystem, you can build a resilient defense that supports your business objectives.

• Identity is Central: Use Microsoft Entra ID as your single source of truth for all SAP access. Federation is the standard; avoid local SAP user management whenever possible.
• Shared Responsibility is Real: Understand that while SAP manages the hardware and OS, you are entirely responsible for user identity, access policies, and data security.
• Zero Trust is Mandatory: Do not trust users or devices just because they are on your corporate network. Use Conditional Access policies to verify identity, device health, and location.
• Visibility is Everything: Use Log Analytics and Microsoft Sentinel to monitor your SAP environment. You cannot secure what you cannot see.
• Automate and Centralize: Use Managed Identities and Azure Key Vault to remove the risk of human error in credential management.
• Regular Audits: Security configurations shift over time. Schedule regular reviews of your SAP roles and Azure NSG rules to ensure they stay aligned with your evolving business needs.

By following these guidelines, you ensure that your migration to SAP RISE on Azure is not just a technical success, but a secure foundation for your company's digital future.

Common Questions (FAQ)

Q: Does SAP RISE on Azure mean I don't need to worry about SAP security patches? A: No. SAP manages the application of the patches, but you are responsible for testing them and approving the maintenance windows. You must stay informed about SAP Security Notes and coordinate with your RISE service manager.

Q: Can I use my existing on-premises Active Directory with SAP RISE? A: Yes. You can sync your on-premises AD to Microsoft Entra ID using Entra Connect. This allows users to use their existing credentials to access SAP RISE applications via SSO.

Q: Is it possible to block access to SAP from specific countries? A: Yes. Using Conditional Access policies in Microsoft Entra ID, you can define "Named Locations" and create a policy that blocks access from any location not on your approved list.

Q: What is the biggest security risk in an SAP RISE environment? A: The most common risk is the misconfiguration of user roles (giving too much power to individual users) and the reuse of weak or compromised passwords for service accounts. Focusing on Identity and Access Management (IAM) is the highest-leverage security activity you can perform.