Securing SAP Integrations with Microsoft Azure and AWS

Why SAP Integrations Create Unique Cloud Security Challenges

SAP systems were designed for on-premises data centers with tightly controlled network perimeters. When you integrate SAP with Azure or AWS, you introduce new data flows, identity mappings, and API surfaces that traditional SAP security architectures were never built to protect. The result is a set of security gaps that standard cloud security posture management (CSPM) and cloud workload protection platforms (CWPP) are not designed to address.

The Application Layer Blind Spot

Most cloud security tools monitor infrastructure—virtual machines, storage accounts, network security groups—but they lack visibility into SAP application-layer events. When a user calls an RFC function module from a cloud-hosted microservice, or when an ABAP program is modified through a BTP integration, the cloud security layer sees network traffic but cannot interpret whether that RFC call is authorized, whether the ABAP change violates segregation of duties, or whether the user context has been manipulated through a Privilege Escalation on SAP.

This blind spot is especially dangerous in hybrid architectures where SAP systems remain on-premises but are accessed through cloud-based identity providers, API gateways, or middleware. The attack surface extends beyond the cloud boundary, yet visibility stops at the network layer.

Identity Federation Risks

When you federate SAP authentication with Azure Active Directory or AWS IAM Identity Center, you inherit the identity security posture of your cloud directory. If a cloud user account is compromised through phishing or weak credentials, the attacker may gain SAP access without triggering any SAP-specific alerts. Standard SAP audit logs show a successful login from a federated user—they do not reveal that the cloud-side identity was compromised 30 minutes earlier.

Consider a scenario where a junior Azure administrator accidentally grants Application Administrator role privileges to an external contractor. That contractor now has potential to modify the SAP Enterprise Application registration in Azure AD, redirecting SAP authentication flows or adding credentials. Without cross-platform monitoring, this chain of events remains invisible until a data breach occurs.

Data in Transit and Compliance Implications

SAP integration with cloud platforms moves sensitive financial data, personally identifiable information (PII), and critical business transactions across network boundaries. Compliance frameworks such as SOX, PCI DSS, GDPR, and ISO 27001 require encryption in transit, but encryption alone is insufficient. You must also ensure that the data payloads are authorized at the application level—not just encrypted at the transport layer.

For example, a payment run triggered from an AWS Lambda function may use TLS encryption, but if the Lambda function was invoked by a compromised API key, or if the RFC destination points to an unauthorized SAP client, the transaction could bypass financial controls entirely. Compliance auditors increasingly look for evidence of end-to-end authorization monitoring, not just encryption.

SAP Security Architecture for Azure and AWS Integrations

Building a secure SAP integration with Azure or AWS requires a defense-in-depth approach that covers identity, network, application, and data layers. Below are the key architectural controls.

Identity and Access Management Controls

The foundation of SAP cloud integration security is proper identity federation design. When using Azure AD to authenticate SAP users, implement the following controls:

• Use Conditional Access policies to require multi-factor authentication (MFA) for SAP application access, with session risk policies that revoke access when suspicious cloud-side activity is detected.
• Restrict SAP Enterprise Application registration to a dedicated security group, not general cloud administrators.
• Map cloud roles to SAP roles through a least-privilege model—do not use blanket role assignments that grant broad SAP_ALL access to federated users.
• Monitor cloud identity logs (Azure AD Sign-in Logs, AWS CloudTrail) alongside SAP security audit logs in a centralized SIEM to detect cross-platform attack patterns.

For AWS-based integrations, implement similar controls using AWS IAM roles tied to SAP user mappings. Use AWS Organizations Service Control Policies (SCPs) to restrict which accounts can create or modify SAP integration resources.

Network Segmentation and Data Flow Security

SAP integration traffic between cloud and on-premises should traverse isolated network paths with strict access controls. Key architecture decisions include:

• Use Azure Virtual Network (VNet) peering or AWS Transit Gateway to route SAP traffic through dedicated subnets with Network Security Groups (NSGs) or Security Groups that allow only required SAP protocols (RFC, DIAG, HTTP/S).
• For RFC-based integrations, use SAP Secure Network Communications (SNC) with an external security product for mutual authentication and integrity protection.
• Implement cloud-side network monitoring that specifically inspects SAP protocol traffic. Tools like Azure Network Watcher and AWS VPC Flow Logs can detect unusual connection patterns, but they require SAP-aware parsing to distinguish legitimate RFC calls from malicious ones.
• Deploy SAP Web Dispatcher or SAP Cloud Connector as a controlled ingress point for cloud-to-SAP communication, rather than exposing SAP application servers directly to cloud subnets.

Common SAP Integration Attack Vectors on Azure and AWS

Understanding how attackers exploit SAP cloud integrations helps you prioritize security controls. Below are the most common attack vectors observed in enterprise environments.

RFC Function Module Abuse Through Cloud Middleware

Attackers who compromise a cloud-based middleware service (Azure Logic Apps, AWS Step Functions, or custom microservices) can invoke SAP RFC function modules that the middleware has legitimate access to. If the middleware account uses a high-privilege SAP service user with RFC access to sensitive function modules like  SUSR_USER_READ  or  RFC_ABAP_INSTALL_AND_RUN , the attacker gains significant SAP control.

This attack vector exploits the gap between cloud authorization (which middleware process is authorized) and SAP authorization (which function modules the process can call). Standard monitoring tools lack the context to flag when a legitimate middleware process suddenly calls a function module outside its historical pattern.

Insider Threats via Direct Cloud-to-SAP Access

A privileged cloud administrator with access to both cloud management interfaces and SAP system credentials can bypass all cloud security controls. For example, an AWS administrator with permissions to modify EC2 security groups could open a direct network path from their workstation to an SAP application server, then use stolen SAP credentials to extract financial data.

This type of attack is particularly dangerous because it uses legitimate access across both domains. Cloud security tools see authorized administrative actions; SAP logs see a normal user login. The only way to detect this is through cross-platform user behavior analytics that correlate cloud-side management activity with SAP-side data access patterns.

SAP BTP ABAP Environment Exploitation

SAP Business Technology Platform (BTP) ABAP environments run ABAP code in cloud-managed containers. While BTP provides some baseline security controls, misconfigurations in authorization objects, communication scenarios, and destination services can expose critical functions. Attackers who gain access to a BTP subaccount can deploy malicious ABAP code that calls back to on-premises SAP systems through cloud connectors, effectively using BTP as a pivot point.

Because BTP runs in Azure or AWS infrastructure, cloud security teams often assume their CSPM tools cover it—but BTP ABAP applications have their own authorization model that cloud tools cannot inspect.

Monitoring SAP Integrations with Azure and AWS

Effective monitoring requires correlating data from cloud platforms, SAP systems, and integration layers. Below are the specific data sources and analysis techniques you need.

Cloud-Side Data Sources and Analysis

Both Azure and AWS provide rich audit logging capabilities, but they require SAP-aware configuration to be useful for integration security.

SAP-Side Data Sources and Analysis

SAP systems generate detailed security audit logs, but they are often underutilized in cloud integration monitoring. Key logs to centralize include:

• SAP Security Audit Log (SM19/SM20): Records user logons, RFC calls, transaction starts, and authorization failures. For cloud integration monitoring, focus on RFC calls originating from cloud subnet IP ranges or service users tied to integration middleware.
• SAP Change Document Logs (SCU0, SCU3): Track changes to critical configuration tables, including RFC destinations, trust relationships, and security parameters. An unauthorized change to an RFC destination pointing to a cloud system is a high-severity indicator.
• ABAP Application Logs (SLG1): Capture application-layer events including custom code execution. Use these to detect anomalous ABAP program execution triggered from cloud integrations.
• SAP Syslog: Forward syslog data to your SIEM for correlation with cloud platform alerts.

The challenge is that SAP logs are voluminous and require SAP-specific parsing rules. A general SIEM without SAP content packs will miss critical indicators such as unauthorized RFC destination changes or segregation-of-duties violations in cloud-triggered transactions.

Purpose-Built Monitoring vs. General SIEM Tools

Many organizations initially attempt to monitor SAP cloud integrations using their existing SIEM tool, only to discover significant capability gaps. While SIEM platforms provide essential log aggregation and correlation, they lack SAP-specific parsers, authorization context, and segregation-of-duties analysis engines. This is a critical distinction when you compare a general SIEM approach against a solution like CyberSilo SAP Guardian.

Implementing SAP Security Monitoring for Azure Integrations

Below is a phased implementation approach for securing SAP integrations with Microsoft Azure. This workflow applies to both Azure AD authentication and Azure-based middleware integrations.

Securing SAP Integrations with AWS: Implementation Guide

AWS-based SAP integrations require similar controls but with AWS-specific tooling and architecture patterns.

Identity and Network Controls for AWS

When integrating SAP with AWS, focus on these critical control points:

• Use AWS IAM roles with restrictive trust policies for SAP integration workloads. Never use long-term access keys for SAP service accounts.
• Implement AWS Organizations SCPs that prevent modifications to SAP-related resources (EC2 instances, VPC peering connections, security groups) from non-authorized accounts.
• Deploy SAP workloads in dedicated AWS accounts managed through AWS Control Tower, with strict network boundaries between SAP accounts and other cloud workloads.
• Use AWS PrivateLink for SAP integration traffic rather than traversing the public internet, and combine it with VPC endpoints for S3, KMS, and Secrets Manager.
• Monitor AWS CloudTrail for unusual API calls related to SAP integration resources, particularly PutSecretValue (credential rotation), AuthorizeSecurityGroupIngress (network access changes), and CreateVpcPeeringConnection (network path changes).

AWS-Specific Monitoring Integration

For AWS-based SAP integrations, forward CloudTrail, VPC Flow Logs, and GuardDuty findings to your central security monitoring platform. However, as with Azure, these sources lack SAP application-layer context. A dedicated SAP monitoring solution enriches AWS log data with SAP authorization details, enabling detection of threats such as:

• A Lambda function calling SAP RFC BAPI_GOODSMVT_CREATE outside approved business hours.
• An EC2 instance in a compromised security group making DIAG protocol connections to SAP systems.
• A Step Functions workflow that invokes SAP transactions in a sequence that violates segregation-of-duties rules.

Compliance Implications for SAP Cloud Integrations

Regulatory compliance adds significant requirements for SAP cloud integration security. Below is how key frameworks treat SAP-to-cloud data flows.

SOX Compliance for SAP on Cloud

SOX Section 404 requires that internal controls over financial reporting are documented, tested, and monitored. When financial transactions flow through cloud-integrated SAP systems, your SOX controls must extend to the integration layer. Key requirements include:

• Segregation of duties controls that cover both cloud-side access (who can configure integration middleware) and SAP-side access (who can execute transactions through that middleware).
• Change management controls that require approval for any modification to RFC destinations, cloud service principals, or integration workflow logic.
• Audit evidence that demonstrates continuous monitoring of financial transactions from cloud initiation through SAP processing to financial statement posting.
• Access recertification processes that jointly review cloud identities and their mapped SAP authorizations.

SOX auditors are increasingly asking to see evidence of automated monitoring at the application layer—manual log reviews are no longer sufficient, particularly for high-volume cloud integrations.

GDPR and Data Sovereignty for SAP on Cloud

When SAP workloads run on Azure or AWS, data residency and data sovereignty become compliance-critical. GDPR requires that personal data be processed only in jurisdictions with adequate protection levels. If your SAP integration moves personal data (employee records, customer financial data, HR information) from on-premises to cloud or between cloud regions, you must:

• Document all data flows and the legal basis for data transfer.
• Implement technical controls to prevent data from being stored or processed in unauthorized regions—this includes cloud-side service controls (Azure Policy, AWS SCPs) and SAP-side controls (RFC destination restrictions, data volume monitoring).
• Ensure that cloud providers process data only according to your instructions (Data Processing Agreement requirements).
• Maintain the ability to delete or restrict processing of personal data in cloud-integrated SAP systems—this requires visibility into where integration data is cached or transformed.

Failure to monitor the full data flow path from cloud integration to SAP system to storage can result in GDPR non-compliance penalties.

Best Practices for Long-Term SAP Cloud Security

Securing SAP integrations is not a one-time project. Below are practices that mature organizations adopt for sustained security posture.

• Continuous discovery: Cloud environments change rapidly. Use automated discovery tools to identify new SAP-related resources, including shadow IT integrations deployed by business units without security team knowledge.
• Automated compliance validation: Deploy infrastructure-as-code policies (Azure Policy, AWS Config Rules) that automatically enforce SAP security baseline configurations—for example, requiring SNC for all RFC destinations and blocking non-approved identity providers from accessing SAP applications.
• Cross-platform user behavior analytics: Implement behavioral baselines that track normal patterns for each SAP-Cloud integration user (both human and service accounts). Alert when a user’s cloud-side activity increases in parallel with SAP-side data extraction volumes—a strong indicator of credential compromise.
• Regular architecture reviews: SAP and cloud architectures evolve. Schedule quarterly reviews of integration security controls, particularly when new middleware services, identity providers, or SAP versions are introduced.
• Vendor security assessment: If your organization uses third-party middleware or integration platforms to connect SAP with Azure or AWS, conduct security assessments that include the vendor’s SAP authorization model, credential management, and audit logging capabilities.

For organizations seeking to streamline compliance reporting and reduce manual monitoring overhead, evaluating the total cost of SIEM ownership alongside specialized SAP monitoring solutions can reveal significant efficiency gains. Many organizations find that a purpose-built SAP security layer reduces the log volume and alert noise in their general SIEM, making both tools more effective.

Common Mistakes in SAP Cloud Integration Security

Based on assessments of enterprise SAP cloud deployments, the following mistakes appear most frequently:

• Treating SAP as just another cloud workload: SAP’s unique authorization model, ABAP runtime, and RFC protocol require specialized security controls. Applying general cloud security policies without SAP adaptation leaves critical gaps.
• Over-relying on cloud-native monitoring: Azure Monitor and AWS CloudWatch provide excellent infrastructure visibility but cannot interpret SAP application-layer events. Organizations that rely solely on these tools miss the most dangerous threats.
• Neglecting service account monitoring: Integration service users often have elevated SAP authorizations and are rarely monitored for behavioral anomalies. A compromised service account can cause massive damage before detection.
• Siloed incident response: Cloud security teams and SAP Basis teams often operate with separate tools, processes, and escalation paths. When an incident spans both domains, response is delayed and evidence is fragmented.
• Insufficient SoD controls at the integration layer: Segregation-of-duties rules that work well for human users break down when applied to middleware service accounts. Organizations must define SoD rules specifically for automated integration flows, considering transaction sequences rather than just individual user authorizations.