Edit

Share via

Secure Azure infrastructure for SAP applications

A well-secured SAP solution incorporates many security concepts with many layers that span multiple domains:

  • Identity management, provisioning and single sign-on (SSO), multifactor authentication (MFA), Global Secure Access, and secure network connection
  • Auditing, log analytics, and event management
  • Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) solutions
  • Antivirus and anti-malware endpoint protection
  • Encryption and key management
  • Operating system hardening
  • Azure infrastructure hardening

SAP applications should be incorporated into the overall Zero Trust security solution for the entire IT landscape. For more information, see the Microsoft Security page about Zero Trust strategy and architecture.

The SAP security solution should reference the Zero Trust security model. A Zero Trust security solution validates each action at each layer, such as identity, endpoint network access, authentication, and MFA, through SAP application and data access.

Diagram of Microsoft Zero Trust design.

The purpose of this article is to provide links and brief descriptions on how to implement identity, security, and audit-related features for SAP solutions running on the Azure Hyperscale service tier. This article doesn't specify which security features you should implement, because requirements depend on risk profile, industry, and regulatory environment. This article does make some general recommendations, such as using Microsoft Defender for Endpoint, transparent data encryption (TDE), and backup encryption on all systems.

If you're designing and implementing identity, security, and audit solutions for SAP, review the concepts in Introduction to the Microsoft cloud security benchmark. You can find more checklists in Secure overview (Cloud Adoption Framework).

Deployment checklist

The design and implementation of a comprehensive security solution for SAP applications running on Azure is a consulting project.

This article provides a basic deployment pattern that covers a minimum security configuration and a more secure configuration. Organizations that require high security solutions should seek expert consulting advice. Highly secured SAP landscapes might increase operational complexity. They also might make tasks such as system refreshes, upgrades, remote access for support, debugging, and testing for high availability and disaster recovery difficult or complex.

Minimum: Security deployment checklist

  • Defender for Endpoint is active in real-time mode on all endpoints (SAP and non-SAP). Unprotected endpoints are a gateway that an attacker can use to compromise protected endpoints.
  • Defender XDR rules are in place for alerting on (and on Windows, blocking) high-risk executable files.
  • Microsoft Sentinel for SAP or another SIEM/SOAR solution is in place.
  • All database management systems (DBMSs) are protected with TDE. Keys are stored in Azure Key Vault or hardware security modules (HSMs), if your environment supports them.
  • Operating system, DBMS, and other passwords are stored in Key Vault.
  • Linux sign-in has passwords disabled. Users can sign in only by using keys.
  • All virtual machines (VMs) are generation 2 with Trusted Launch enabled.
  • Storage accounts use platform-managed keys (PMKs).
  • VM, HANA, SQL, and Oracle backups go to an Azure Backup vault with immutable storage.

More secure: Security deployment checklist

  • Defender for Endpoint is active in real-time mode on all endpoints (SAP and non-SAP). Unprotected endpoints are a gateway that an attacker can use to compromise protected endpoints.
  • Defender XDR rules are in place for alerting on (and on Windows, blocking) high-risk executable files.
  • Microsoft Sentinel for SAP or another SIEM/SOAR solution is in place.
  • All DBMSs are protected with TDE. Keys are stored in Key Vault or HSMs, if your environment supports them.
  • Operating system, DBMS, and other passwords are stored in Key Vault.
  • Linux sign-in has passwords disabled. Users can sign in only by using keys.
  • All VMs are generation 2. Trusted Launch, boot integrity monitoring, and host-based encryption are enabled for all VMs.
  • All VMs support Intel Total Memory Encryption (TME).
  • Storage accounts use PMKs for general storage and customer-managed keys (CMKs) for sensitive data.
  • VM, HANA, SQL, and Oracle backups go to an Azure Backup vault with immutable storage.
  • There's a stronger segregation of duties among SAP Basis, backup, the server team, and security/key management.

Defender for Endpoint

Defender for Endpoint is the only comprehensive antivirus and SAP Endpoint Detection and Response (EDR) solution that's comprehensively benchmarked and tested with SAP benchmarking tools and documented for SAP workloads.

Defender for Endpoint should be deployed on all NetWeaver, S/4HANA, HANA, and AnyDB servers without exception. The following deployment guides cover the correct deployment and configuration of Defender for Endpoint with SAP applications:

Defender XDR

In addition to antivirus and EDR protection, Defender can provide more protection through features and services:

Microsoft Secure Score and Defender Vulnerability Management are discussed in the section about OS-level hardening later in this article.

Microsoft Sentinel for SAP connectors

The Microsoft Sentinel SIEM/SOAR solution has a connector for SAP. SAP application-specific signals, such as user logons and access to sensitive transactions, can be monitored and correlated with other SIEM/SOAR signals, such as network access and data exfiltration. For more information, see:

Database-level encryption: TDE and backup encryption

We recommend that you enable TDE for all DBMSs that run SAP applications on Azure. Testing shows that the performance overhead is 0% to 2%. The advantages of TDE far outweigh the disadvantages.

Most DBMS platforms create encrypted backups if the database is enabled for TDE. This configuration mitigates one common attack vector: theft of backups.

SAP HANA doesn't support storing keys in Azure Key Vault or any other HSM device. For more information, see SAP Note 3444154: HSM for SAP HANA Encryption Key Management. To enable TDE on HANA, see Enable Encryption in the SAP Help Portal.

SQL Server TDE is fully integrated into Key Vault. For more information, see:

Oracle DBMS supports TDE in combination with SAP applications. Keys for TDE can be stored in HSM PKCS#11 devices. For more information, see:

DB2 native encryption is supported in combination with SAP applications. Encryption keys can be stored in HSM PKCS#11 devices. For more information, see:

Key management: Azure Key Vault and HSM

Azure supports two solutions for key management:

  • Azure Key Vault: A native Azure service that provides key management services (not PKCS#11 compliant).
  • Azure Cloud HSM: A hardware-level, PKCS#11, FIPS 140-3 Level 3, single-tenant solution.

For more information on these services, see:

We recommend that you store OS and application passwords in Key Vault. For training on secret management, see Manage secrets in your server apps with Azure Key Vault.

Defender for Key Vault can alert you if suspicious activity occurs in Key Vault. For more information, see Overview of Microsoft Defender for Key Vault.

OS-level hardening

Operating system patching is one key layer in a secure solution. It isn't possible to consistently and reliably update VMs at scale manually without the use of patch management tools. You can use Azure Update Manager to accelerate and automate this process.

Note

Linux kernel hotpatching has restrictions when the target VMs are running Defender for Endpoint. Review the documentation about using Defender for Endpoint with SAP, as listed earlier in this article. Linux patching that requires OS reboot should be handled manually on Pacemaker systems.

You can use Microsoft Secure Score to monitor the status of a landscape.

SUSE, Red Hat, and Oracle Linux

High-priority items for Linux operating systems include:

Here are resources for hardening Linux OS distributions:

SELinux

SELinux is supported on the latest Red Hat Enterprise Linux (RHEL) releases. Microsoft supports running SAP workloads on RHEL in accordance with SAP and Red Hat guidance. Microsoft does not deliver, or provide support on managing SELinux policies. Customers are responsible for configuring, maintaining, and validating any SELinux policy changes required for their environments.

For more details about SELinux on RHEL, see:

Windows operating systems

High-priority items for Windows operating systems include:

  • Use generation 2 VMs with Secure Boot.
  • Minimize the installation of any third-party software.
  • Configure Windows Firewall with minimal open ports via Group Policy.
  • Enforce SMB encryption via Group Policy. For more information, see Configure the SMB client to require encryption in Windows.
  • After installation, lock the <SID>adm username as described in SAP Note 1837765: Security policies for <SID>adm and SAPService<SID> on Windows. The service account SAPService<SID> should be set to deny interactive login (the default setting after installation). The SAPService<SID> and <sid>adm accounts must not be deleted.
  • Configure Windows Group Policy to clear the last user name after you permit Active Directory authenticated sign-in. This configuration mitigates cloning attacks. Disable legacy TLS and SMB protocols.

Here are resources for Windows OS distributions:

Azure infrastructure security

You can enhance your Azure infrastructure security configuration to reduce or eliminate attack vectors.

Generation 2 VM and Trusted Launch

We recommend that you deploy only generation 2 VMs and activate Trusted Launch. For more information, see the following Microsoft article and blog post:

Note

Only recent versions of SUSE 15 support Trusted Launch. See the list of supported operating systems.

The conversion from generation 1 to generation 2 can be complex, especially for Windows. We recommend that you deploy only generation 2 Trusted Launch VMs by default. For more information, see Upgrade existing Azure Gen1 VMs to Trusted launch.

For the list of Azure VMs supported for Trusted Launch, see Virtual machine sizes.

Defender for Cloud can monitor Trusted Launch. For more information, see Microsoft Defender for Cloud integration.

Encryption in transit for Azure Files NFS and SMB

You can encrypt Network File Share (NFS) traffic in Azure Files to help protect against packet tracing and other threats. For more information, see:

For SMB, Azure Files supports encryption in transit by default. For more information, see SMB file shares in Azure Files.

Encryption at host

To verify that M-series VMs have the latest drivers required for encryption at host, contact Microsoft. M-series v3, D-series, and E-series VMs can use encryption at host without restriction.

Encryption at host is tested with SAP, and you can use it without restriction on modern Azure VMs. The overhead is around 2%.

For more information about this feature, see:

Storage account encryption

Storage accounts use either PMKs or CMKs. Both are fully supported with SAP applications. For more information, see Azure Storage encryption for data at rest.

CMKs within one tenant or across tenants are supported. For more information, see Encrypt managed disks with cross-tenant customer-managed keys.

You can use double encryption at rest for highly secure SAP systems. For more information, see Enable double encryption at rest for managed disks. This capability isn't supported on Azure Ultra Disk Storage or Premium SSD v2 disks.

For a comparison of disk encryption technologies, see Overview of managed disk encryption options.

Important

Azure Disk Encryption isn't supported for SAP systems.

Virtual network encryption

Consider using virtual network encryption for high-security deployments and gateways. There are some feature restrictions. Virtual network encryption is currently used for specific high-security scenarios.

Intel Total Memory Encryption

Modern Azure VMs automatically use the Total Memory Encryption - Multi-Key (TME-MK) feature built into modern CPUs. High-security customers should use modern VMs and contact Microsoft directly for confirmation that all VM types support TME. For more information about the feature, see the Intel TME-MK documentation.

Azure Automation account for Azure Site Recovery agent updates

To change the Azure Automation user account required for Azure Site Recovery agent updates from Contributor to a lower security context, review the latest documentation for Site Recovery.

Removal of public endpoints

Public endpoints for Azure objects such as storage accounts and Azure Files should be removed. For more information, see:

DNS hijacking and subdomain takeover

You can prevent subdomain takeovers by using Azure DNS alias records and custom domain verification in Azure App Service. For more information, see Prevent dangling DNS entries and avoid subdomain takeover.

In addition, you can use Defender for DNS to help protect against malware and remote access trojan (RAT) command-and-control targets. For more information, see Overview of Microsoft Defender for DNS.

Azure Bastion

Azure Bastion can help prevent system administrators' workstations from becoming infected with malware such as key loggers. For more information, see the Azure Bastion documentation.

Ransomware protection

The Azure platform includes powerful ransomware protection features. We recommend that you use an Azure immutable vault to prevent ransomware or other trojans from encrypting backups. Azure offers write once, read many (WORM) storage for this purpose.

Azure Backup for SAP HANA and SQL Server can write to Azure Blob Storage. For more information, see Backup and restore plan to protect against ransomware. It's possible to configure storage to require a PIN or MFA before anyone can modify backups.

You can configure fully locked, SEC 17a-4(f)-compliant immutable storage policies. For more information, see Lock a time-based retention policy.

We recommend that you review Steps to take before an attack and select the appropriate measures.

Here are more resources:

In addition, Microsoft offers support and consulting services for security-related topics. See the Microsoft blog post DART: the Microsoft cybersecurity team we hope you never meet.

Further recommendations for large organizations include segregation of duties. For example, SAP administrators and server administrators should have read-only access to the Azure Backup vault. You can implement multi-user authorization and a resource guard to help protect against rogue administrators and ransomware.

You can achieve extra protection from ransomware by deploying Azure Firewall Premium. For more information, see Improve your security defenses for ransomware attacks with Azure Firewall Premium.

Unsupported technologies

Azure Disk Encryption isn't supported for SAP solutions. RHEL and SUSE Linux Enterprise Server (SLES) Linux images for SAP applications are considered custom images, so they aren't tested or supported. Customers who have a requirement for at-rest encryption typically use Azure encryption at host.

Important

Azure Disk Encryption is now a deprecated feature. For more information, see Azure Updates.

SAP Security Notes

For information about SAP Security Notes, go to the entry point or the searchable database.

SAP releases information about vulnerabilities in its products on the second Tuesday of every month. Vulnerabilities with a Common Vulnerability Scoring System (CVSS) score between 9.0 and 10 are severe, and we recommend that you mitigate them immediately.

Security analysts and forums have reported an increase in the exploitation of SAP-specific vulnerabilities. Vulnerabilities that don't require authentication should be expedited through the SAP landscape.

Related content

  • Last updated on