AWS Security Solutions for SAP S/4HANA (I): Identity and Access Management

Leading companies adopt SAP capabilities to meet their business requirements and respond quickly to the ever-changing marketplace. And as SAP transforms business processes through intelligent automation with its refreshed product set, so too does the security risk.

As specialists in SAP and AWS environments and aware of the relevance this issue has for everyone, Mario de Felipe, our Director of Business Development, starts with this article a series of five posts in which he will delve into the options offered by the cloud platform to ensure the security of SAP S/4HANA.

New SAP system implementations, SAP upgrades and conversions to S/4HANA are now being done in the cloud, and the threat landscape is changing. With any cloud provider, customers must take a holistic approach to securing SAP systems, protecting all SAP data generated by devices, endpoints, users, applications, databases and third-party systems across on-premises, hybrid and multi-cloud environments.

Early 2021, SAP announced a Go-To-Market program called Rise with SAP, which gives a message to the customers, with an easy path to upgrade their SAP systems to S/4HANA using the cloud providers. 

Cloud providers make it easy to migrate SAP systems from on-premises to the cloud, promising lower TCOs and IT agility. Therefore, customers have to decide whether to continue deploying applications in their own data centers or move them to the cloud to free employees from maintaining IT to do more innovative tasks, resulting in faster digital transformation and increased competitiveness for the enterprise. It is not an easy decision when considering that various network security solutions need to be deployed.

AWS leverages its extensive threat intelligence, a strong portfolio, and state-of-the-art artificial intelligence (AI) and machine learning (ML) security to provide a seamless security experience across our SAP landscapes. It automates security controls, making it easier to manage, respond, and automate the SecOps capabilities.

If SAP Security was not a big concern before, it should be now

According to Canalys, 2020 saw a record spending in Cybersecurity but also record data breaches, and 2020 saw more breaches than the previous 15 years combined.

Source: Canalys

While Protecting SAP solutions is top of mind, Global cyber-crime damages will reach $6 trillion by 2021 and the years to come, according to Canalys. With S/4HANA, and other SAP solutions, comes SAP Fiori, a web interface for users that increasingly replaces the SAP GUI. Fiori, an HTML5-based front end, is a target for attacks. SAP security risks exist

Currently, SAP does not provide guidance on infrastructure security. It does not provide any rules on how SAP systems can prevent security attacks with today’s technologies available to cybercriminals.

Vulnerability Scanning Activity related to CVE-2020-6287 over time. Source, Onapsis report.

Some of the vulnerabilities of SAP have been exploited in recent times, as we see in the image. Authorities had to give these vulnerabilities codenames such as RECON or 10KBLAZE. Every month SAP publishes security advisories about current vulnerabilities or bugs that could endanger the entire SAP landscape. These notes should be implemented in the SAP systems ASAP, and some others at regular intervals to ensure secure operation. Let’s remember the application security task always remain in customer’s responsibility.

RECON (released in 2020) shares similarities to 10KBLAZE, released in 2019 and both put the confidentiality, integrity, and availability of SAP data and processes at risk. What do these two exploits have in common? They are leveraging a lack of visibility and control to be successful. There is a reason that these exploits focus on the creation of admin accounts – because once someone is an admin (legitimate or not), he has the control.

Modern attacks like the Chinese Hafnium targeting Microsoft Exchange (stealing entire mailboxes) or the Russian hacking of Solarwinds, where attackers exploited the victim’s identity by gaining their personal information, impersonating the user, and gaining access to the victim’s Azure and Microsoft 365 accounts, give a message, no one is safe from a global cyberattack campaign, and the goal is to affect as many companies as possible.

Why this post matters for SAP customers

1. Business impact. Suppose an attacker can gain access to an unprotected SAP system by exploiting a vulnerable internet-facing application or executing an attack from inside the organization on insecure systems. In that case, the business impact could be critical. In many scenarios, the attacker would access the vulnerable SAP system with the highest privileges (Administrator/SAP_ALL), bypassing all access and authorization controls (such as segregation of duties, identity management, and GRC solutions). It means that the attacker could gain complete control of the affected SAP system, its underlying business data, and processes. Having administrative access to the system would allow the attacker to manage (read/modify/delete) every record, file, and report in the system.
2. Regulatory Compliance Impact. For many organizations, mission-critical SAP applications are under the supervision of specific industry and governmental regulations, financial and other compliance requirements. Any enforced controls that bypass via exploitation of threats discussed in this report might cause regulatory and compliance deficiencies over critical areas such as GDPR or Sarbanes-Oxley due to unauthorized changes to financial data or bypassing of internal controls. For organizations that must meet regulatory compliance mandates, this would trigger an audit failure and violate compliance. The result could lead to potential disclosure of the violation, expensive third-party audits, and penalties that could include fines and legal action.

I presented best practices and recommendations for implementing a secure SAP S/4HANA with AWS intelligent technologies in this post. I highlight the most common attack vectors on SAP and how AWS’s portfolio can address those vectors by taking a preventative and detecting role in SAP environments. It’s not a generalist SAP Security Blog, but how AWS can help to secure the SAP systems.

Source: Linke

Introduction to the series

Specific recommendations or regulations regarding network, operating system or client security (infrastructure security) are relevant. Still, SAP does not provide any rules on how SAP systems can prevent security attacks with today’s technologies available to cybercriminals. Here’s where AWS adds value to ensure a secure SAP environment.

Any SAP customer running on AWS is entitled to cover his part of the responsibility in the Shared Responsibility Model.

When we begin working in AWS, the most critical security (and, to a certain point, operational) principle that we must understand is who is responsible for what. Who is accountable for patching the OS? Who is responsible for encrypting data-at-rest? Who is accountable for application security? Who is liable for regulatory compliance? As it turns out, we are — for all of these.

Under the AWS shared responsibility model, AWS provides a global secure infrastructure and foundation compute, storage, networking, and database services. Essentially, everything up to and including the hypervisor is the responsibility of AWS. We, the users, are responsible for protecting the confidentiality, integrity, and availability of the data in the cloud and meeting specific business and compliance requirements.

Under this series of posts, the focus will primarily be on the environment and application security of the SAP Secure Operations Map while also focusing on the ecosystem surrounding it, including segmentation, web application firewall (WAF) security, and the recommended network security practices.

IAM (Identity and Access Management)

Source: Linke

IAM is about Identity for AWS accounts, Users, Groups, Roles, and Policies. All of this can be complex, and it is easy to do incorrectly. Applications that run on an Amazon EC2 instance need credentials to access other AWS services. For example, we need to create a role for an SAP HANA instance to access the S3 bucket to configure the AWS Backint. To allow our Amazon EC2 instance to access a target Amazon S3 bucket, we must create or update an inline IAM policy with the permissions and attach it to the EC2 service role. We must protect every access, from Applications to Users.

AWS Account Management and Separation

The recommendation is to separate workloads and group accounts based on function, compliance requirements, or a standard set of controls rather than mirroring our organization’s reporting structure. In AWS, accounts are a rigid boundary, zero trust container, for the resources. For example, account-level separation is strongly recommended for isolating production workloads from development and test workloads.

There are many aspects to securing our AWS accounts, including obtaining, not using the root user, and keeping the contact information up to date. We can use AWS Organizations to centrally manage and govern our accounts as we grow and scale our workloads in AWS. 

AWS Control Tower offers a simplified way to set up and govern multiple accounts. It automates the setup of accounts in our AWS Organization, automates provisioning, applies guardrails (which include prevention and detection), and provides us with a dashboard for visibility.

Keeping SAP Prod separated from SAP non-Prod environments is an increasing customer approach. Today, many AWS customers use separate AWS accounts (usually in conjunction with Consolidated Billing) for their development and production resources. This separation allows them to separate different types of resources cleanly and provide security and compliance benefits.

Source: Linke

Identity Management

There are two types of identities we need to manage when approaching operating secure AWS workloads.

• Human Identities: The administrators, developers, operators, and consumers of the SAP require an identity to access the AWS environments. These can be members of our organization or external users via web browsers, client applications, mobile apps, or interactive command-line tools.
• Machine Identities: SAP workloads that require an identity to interact with AWS services, for example, to read data. These identities include machines running in our AWS environment, such as Amazon EC2 instances or AWS Lambda functions.

We can use centralized identities for AWS with a SAML 2.0-based provider with AWS IAM for federation with individual AWS accounts.

We can use SAP as a provider since it’s compatible with the SAML 2.0 Protocol or Active Directory using AWS Directory Service, and federate our AWS account with our chosen provider to grant access to AWS API operations with SAML assertion and get temporary security credentials.

For managing end-users or consumers of our workloads, such as a mobile app, we can use Amazon Cognito. It provides authentication, authorization, and user management for our web and mobile apps.

Patrick Leung, a Solution Architect at AWS, created an exciting post about AWS Single Sign-On integration with SAP Fiori in S/4HANA. The article describes how to leverage AWS SSO, an Amazon service that recently offers built-in SSO integrations to SAP, enabling SAP users to access the Fiori launchpad without logging in and out each time.

One step further is to implement MFA for Fiori. For this, AWS Solution Architects Ferry Mulyadi and Kyaw Soe Hlaing created a post, Securing SAP Fiori with Multi-Factor Authentication on AWS. It describes a how-to guide for SAP customers to implement multi-factor authentication (MFA) for SAP Fiori using Microsoft Active Directory as the directory service and AWS Single Sign-On (AWS SSO) to manage the MFA devices.

However, if we plan to use AWS Single Sign-on with other SAP products, not only Fiori, AWS Solution Architect Manoj Muthukrishnan created two exciting posts, enabling SAP Single Sign-On integration with SAP Netweaver Java and ABAP (WebDynpros).

AWS Secrets Manager

AWS Secrets Manager helps to protect secrets needed to access the applications and services, rotating, managing, and retrieving database credentials, API keys, and other secrets throughout their lifecycle.

AWS Architects Kenny Rajan and Marcel Toerpe show how to use AWS DevOps Tools to set up a simplified CI/CD pipeline for SAP Fiori while storing the SAP secrets with AWS Secrets Manager, keeping SAP NetWeaver ABAP environment username, password, and hostname as secrets.

Another idea to leverage AWS Secrets Manager with SAP is described in the post by AWS Architects Arjun Venkateswarlu and Chris Williams, “Extracting data from SAP HANA using AWS Glue and JDBC”.

Using AWS Secrets Manager to store our SAP credentials, we meet the security and compliance requirements by rotating secrets safely without the need for code re-deployments. The goal is to manage access with fine-grained policies from AWS Identity and Access Management (IAM) and secure and audit secrets centrally by encrypting them with keys that we operate using AWS Key Management Service (KMS).