SAP Community - Security

SAP Cloud Integration: Understanding the XML Encryption Standard

2024-03-07T15:16:11.555000+01:00

SAP Cloud Integration doesn’t offer an encryptor step for encrypting XML content according to the "XML Encryption" standard. That standard provides some benefits and flexibility specifically for xml content.
This article is intended to introduce into the "XML Encryption" standard, as preparation for future hands-on.
I'm trying to explain everything simple, with my simple understanding and my simple words - this is not a professional article.
In this blog post, I will try to answer many questions and show examples.
The next blog post shows how we can encrypt / decrypt XML payloads, according to the XML-Enc spec, manually in a Groovy script.

Overview

Historical Intro
Theoretical Intro
XML Sample Intro
Optional Outro

History

How I imagine that it started:
Timmy from Texas wanted to share some secret info with his friend Taku in Tokyo.
So he encrypted a message and sent it to Taku.
Taku was unable to decrypt and read the message.
So Timmy travelled to Tokyo to enjoy some food and to explain the way how he encrypts and packages his messages.
Afterwards, Taku in Tokyo was able to decrypt and read all messages (even before breakfast).
Some time later, same situation happened with his friend Toto in Togo.
Although the food is said to be great, Timmy decided not to travel, but to invite his friends for a conference at home.
They had international food, late-night discussions and at the end, they agreed on a common way of sending secure messages.
As a consequence, everybody in the world can send secure messages and the recipients can understand the message, as long as they follow that agreement.

Does that make sense?
Really makes sense, especially the section about the international food (which didn’t make it into the specification).

What do we learn from this story?
People communicating with each other need to agree on some basic principles:
- how encryption is done, which steps in which order
- what exactly is encrypted
- which algorithms are used
- certificate information
- where is that information stored

This intro was copied from my cms-post.

Introduction

We’re talking about sending data from somewhere to anywhere over the internet.
Instead of writing a letter, we use XML to structure the data which we send.
As we know that the internet is dangerous, we want to encrypt the data.

There are blogs out there?
Sure, we already have so fantastic blog posts like this one together with the intro blog.
It explains how to use the CMS standard for encrypting a message.

So why do we need this blog?
Actually, the CMS standard is not specific to any kind of payload, so it could be used for XML as well, why not.
But...
But we need this blog post because it is specific to XML payload.
As the message is written in XML, we can take advantage of the fact that the content is structured already.
This is a benefit.
So we have an extra standard.

OK. What is the benefit?
As we’re dealing with xml, which is a structured content, we have the advantage of choosing which content or part of content we want to encrypt.

Cool. Which content can we choose?
There are 3 possibilities:

Encrypt the whole document, i.e. the whole file or the entire message
Encrypt part of the document: choose one node of the XML document.
In this case, the node itself is not encrypted, but only the content below the node.
Means, the text content of the node is sensitive, but the node name is left as plain text
The content can be a subtree of child nodes as well.
Encrypt part of the document: again, choose one node of the XML document.
But in this case, the node itself is encrypted as well, along with all of it content.

Variant 1…?
Ummmmm - yes, it is similar as CMS....
AHA
Ehm, yes, here the benefit is less obvious, but nevertheless, the result is an XML with a specific structure, which can be understood by XML-Enc-aware tools.

Don’t understand.
Remember the funny history story?
At the end, a standard is an “agreement” between sender and receiver.
If they both adhere to the agreement, they can send and receive, encrypt and decrypt without trouble.
So even in case of variant 1, the receiver can find the info about how to decrypt, by reading XML.

What is the XML-agreement?
Basically, in case of "XML Encryption" agreement, the receiver knows where to find the information that he needs for decrypting:

The incoming XML contains a node <EncryptedData> which contains everything: the encrypted content and metadata.
There’s the info about which variant (see above) was used
The subtree of this node contains info about the algorithm used to encrypt the content
The subtree contains info about the key that was used to encrypt the content
The encrypted key itself
The encrypted content itself
. . .

Note that the standard is flexible and there are multiple ways to apply it.
In this blog post we’re sticking to one variant which is common and safe and makes sense.

How is encryption done?
During encryption, the sensitive content is replaced by an <EncryptedData> node.
The subtree of <EncryptedData> contains the sensitive content that has to be secured, in non-understandable way, i.e. encrypted.
After encryption, the result is encoded with Base 64, (this is common practice when sending data over the internet).

How is it encrypted?
We have to understand the 2 basic ways of encrypting:
Symmetric and asymmetric encryption

What is symmetric encryption?
Sounds normal: some content is encrypted with a key.
For decryption, the SAME key is used.
Means, the key must be handed over to the recipient in a safe way.
This is a disadvantage.
The advantage: fast and can handle big-sized content.

And asymmetric?
To avoid the problem of having to transmit the secret key:
Here we have 2 keys, which belong together: private and public keys.
This is called a key pair.
The public key is not secret, it can be sent to the encryptor.
The content is encrypted with the public key.
ONLY the private key can then decrypt the content.
Advantage: more secure.
Disadvantage: not applicable to big payloads and slow.

So both are unusable?
There's a solution: use both in a hybrid mode.
Use symmetric key to encrypt the (big) content.
Use asymmetric key to encrypt the (small) symmetric key.
That’s it.
The symmetric key can be safely sent together with the encrypted content.
Because the symmetric key is securely encrypted.
The receiver can decrypt the symmetric key, (because he has the private asymmetric key).
Then use the symmetric key to decrypt the content.

Confusing...
Let’s repeat:
We want to encrypt sensitive content
-> we use a “Content Encryption Key” == CEK
-> also called “Data Encryption KEY” == DEK
This key has to be encrypted with another key.
-> We use a “Key Encryption Key” == KEK

Why can't we just use the KEK to encrypt the message?
As mentioned, because KEK is asymmetric and thus not suitable for big content.

Ah, already forgot
No prob.

What is a key?
What we want to achieve is to hide secret content from someone but reveal it to us.
We want to make it look random, but be able to revert.
Thus we need to use a key, so we are able to revert.
Note:
A key can be just a sequence of bits, but longer key length ( key size) is more safe.

What is a DEK or CEK?
Data Encryption Key or Content Encryption Key.
This is a symmetric key for encrypting the payload content.

What is a KEK?
Key Encryption Key, this is usually an asymmetric key.
Also referred to as “Key Transport”.

How is encryption done?
Think about a rule, e.g. replace every ‘a’ with a ‘b’
Such rule is called “algorithm” or “cipher”.
To make the process reversible, a key is applied.
This makes it reversible only for the key owner.

Examples for symmetric algorithms?
AES, DES (not safe!), TDES (== Triple DES == 3DES == DESede), RC4 (etc, not safe)

Examples for asymmetric algorithms?
RSA, DSA, ECC

What is AES?
It stands for Advanced Encryption Standard.
It is a symmetric-key algorithm.
It works on blocks with size 128 bits.
It supports keys with sizes 128, 192 and 256 bits.

What is a Block Cipher?
In symmetric cryptography, 2 ways are used: block and stream ciphers.
In case of stream, the input is encrypted byte by byte.
In case of block, the content is cut into blocks, which are then encrypted.

What is block size?
The size of such blocks.
AES always operates on blocks of 128 bits.

What is padding?
Assume we have some content which has to be encrypted with AES.
Obviously, it is larger than 128 bits, or a multiple.
Which is the size of a block.
After cutting the content into blocks of 128 bits, there will be a remaining rest.
The rest has to be filled up until 128 is reached.
That’s what we call padding.

What is operation mode?
Assuming again, the content which has to be encrypted is larger than 128 bits.
So it is cut into multiple blocks.
Encryption will be applied to many blocks individually.
The way how this is done, will help to make the encryption more safe.
At the end we want a result that looks completely crazy (= random bytes).
Therefore, we can choose an encryption mode (= operation mode).
Examples:
ECB, Electronic Code Block, unsafe.
Note that ECB is often used as default, if no operation mode is specified.
So the recommendation is to always specify a secure operation mode.
CBC, Cipher Block Chaining, not recommended.
CTR, Counter
GCM, Galois Counter Mode, recommended.

Can we find an end?
We’ve talked about the XML structure and the encryption process.
Now we’ve found the end:
->here

Can we look at an example?
The next chapter is full of xml.

Sample XML

Let’s view a simplified example.
We have a Sales Service that sends info about an order:

Order number
Product Identifier
Customer info
Payment: credit card number
. . .

The service sends the payload in XML format.
XML is tedious to read, so trying to simplify:

We can quickly identify a security risk:
Sending credit card number via the internet is not acceptable.

So we could encrypt the number and send the XML as below:

However, it is better to stick to the XML Encryption standard:

The next screenshot below shows that the content of a node has been replaced with the <EncryptedData> subtree (simplified).
Remember the 3 variants above? So this is the second:
only the content is encrypted, not the whole element + content.
With other words: the credit card number is unreadable, but the <CreditCard> node is still readable.

Next screenshot shows the final result XML structure:

The last screenshot shows the final result:

What we can see:

The top level <EncryptedData> node has 3 children
- EncryptedData
--- EncryptionMethod
--- KeyInfo
--- CipherData

Explanation

🔸EncryptionMethod
This is the information about how the content was encrypted.
In our example, the symmetric cipher AES was used with a key size of 256 bits and operation mode GCM.

🔸CipherData
The result of encrypting plain text is called “ciphertext” and it is stored below this node.
Note that the cipher text is base64-encoded.

🔸KeyInfo
In our example, we chose to encrypt the symmetric key.
The <KeyInfo> node carries the information about this symmetric key
(Remember, this is the key that was used to encrypt the content).
The <KeyInfo> has the following children:
- KeyInfo
---- EncryptedKey
------- EncryptionMethod
------- CipherData

In our case, it contains the encrypted key itself and the method that was used for encryption.
Example: We use an RSA public key for encrypting the DEK, so the <EncryptionMethod> node will contain something with “…rsa…”

Note:
The algorithms are specified via URI, e.g.

<xenc:EncryptionMethod Algorithm=http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p />

We can see the nice little namespace xenc
I like this one 😁
It is specified at top level node:

<xenc:EncryptedData xmlns:xenc=http://www.w3.org/2001/04/xmlenc#

OK.
Let’s add one more last screenshot, where we can compare the XML payload before and after encryption:

Note:
The receiver has to know which variant was used:
If the only the content was encrypted, or the whole element.
This is specified in the “Type” attribute of the top-level element:

<xenc:EncryptedData Type=http://www.w3.org/2001/04/xmlenc#Content
or
<xenc:EncryptedData Type=http://www.w3.org/2001/04/xmlenc#Element

And here comes one last (really last) screenshot, showing the result of encrypting with the variant 3, which is of Type ...xmlenc#Element:

In above screenshot we can see that the <CreditCard> node has disappeared.
The node itself has been replaced with the <EncryptedData> node.
In the groovy script below, we’ll see the flag that decides upon the type.

Optional Info

The “XML Encryption” is also called “XML-Enc”.
It is a standard that is specified as a W3C Recommendation.
It is owned by the World Wide Web Consortium aka W3C.
The W3C owns most standards related to the World Wide Web.
The current version 1.1 of the specification for XML Encryption Syntax and Processing is from 2013.
It can be found here: https://www.w3.org/TR/xmlenc-core1/

Implementations of the standard are available for C, C++ and Java.
The Java implementation is used in our next blog post.

Summary

The XML Enc specification describes how to flexibly encrypt parts of an XML document.
(Or the whole).
The sensitive xml-section is replaced by a new <EncryptedData> section.
This xml-tree contains the encrypted content and metadata (method, key, etc)
The spec is flexible and open, but the common process of encryption would be:
▶️ Generate a symmetric key on the fly.
▶️ Encrypt the content with it.
▶️ Encrypt the symmetric key with an asymmetric key.

Next Steps

Go through the tutorial in the next blog post to gain hands-on experience.

Links

W3C recommendation XML Encryption Syntax and Processing V 1.1
Apache Santuario
Understanding CMS (PKCS 7) standard.
Security Glossary Blog

🌵

Oil & Gas - Ultimate Data Security - Blockchain Data Backbone from OT to SAP IT🚀

2024-03-18T08:58:40.889000+01:00

The Problem

One of the Oil & Gas Industry's biggest challenges is protecting the data which is flowing from UpStream OT Operational Technology to SAP IT Information Technology.

Due to the very nature of Oil & Gas operations, more often than not, the OT Operational Technology is located in geographically remote places, and a long way from the SAP Information Technology and DataCenter.

The OT Data is the most vulnerable, the most exposed to threats when it is flowing from the UpStream Sectore, the "E & P" Exploration and Production, to the SAP IT systems in the DataCenter:

SAP Oil Gas Operations Technology Data Risk Integration to S4HANA Industry Cloud atkrypto.io

The Threat:

The biggest threat to getting data from the Oil & Gas Operational Technology to the SAP Information Technology, is the threat of Cyber Attacks. The attack vector at most risk is the movement of the data, or the data on the move, the integration between the OT and the SAP IT.

In their March 2023 Report, "How to enhance the cybersecurity of operational technology environments", McKinsey and Company highlight the need for "strengthening technological foundations", and in particular, highlighting that,

"integration between OT systems and ERP systems increase the need for secure convergence between the IT and OT environments"

Courtney Schneider, in the report, "OT security incidents in 2021: Trends & Analysis," Waterfall Security Solutions, May 17, 2022, noted that,

"OT cyberattacks tend to have higher, more negative effects than those in IT do, as they can have physical consequences (for example, shutdowns, outages, leakages, and explosions). Of 64 OT cyberattacks publicly reported in 2021 (an increase of 140 percent over the number reported in 2020), approximately 35 percent had physical consequences, and the estimated damages were $140 million per incident."

Today's Legacy Approach to Integration Security

Data Security has evolved slowly during that last 30 years:

Evolution of Data Security atkrypto.io

Data Encryption is not enough

Encryption is not enough atkrypto.io

The Business Demand

The Oil & Gas industry is demanding more, the Business is demanding better security of integration between OT and SAP IT.

The Digital Transformation of Information Security is Enterprise Blockchain, The Next Generation Data Integrity, Originality, Confidentiality Protection

Enterprise Blockchain, Enterprise Distributed Ledger Technology is re-imagining information security.

Enterprise Blockchain Platforms bring, out of the box, natively, a level of security which is not possible out of the box, natively, with any other commercial database product.

What is so special about the Enterprise Blockchain, (and discussed in the previous blogs, here, here, and here) is that Blockchain Distributed Ledger Technology has four special characteristics which make it information security re-imagined, and the next generation of information security, these special characteristics are:

atkrypto.io what is a blockchain SAP Oil Gas OT IT

McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time". If we just pause for a moment and let that sink in, and think about what that means, to Business Processes, to Collaboration, to System Resilience, we start to see what is so special about Blockchain Databases and Distributed Ledger Technology.

This means, we can have the an Enterprise Blockchain Database Tenant running at the Oil & Gas E&P OT sector and an Enterprise Blockchain Database Tenant running at the SAP DataCenter location, and the same data available in both places and protected to the highest level by the Blockchain's Hash Mechanism, Consensus Mechanism, Immutable status, and Distributed resilience.

We can now run Enterprise Blockchain Database from the Exploration and Production sector to the SAP system in the DataCenter, protecting the OT Data as it flows to the SAP IT, to a level of security protection that was not possible with the previous generation of technology:

Blockchain Next Generation Data Protection SAP Oil Gas OT IT atkrypto.io

Wrapping Up and Reference Architecture

To wrap up, a simple reminder,

The Digital Transformation of Information Security is Enterprise Blockchain

Enterprise Blockchain is the Next Generation Data Integrity, Originality, Confidentiality Protection

Enterprise Blockchain, Enterprise Distributed Ledger Technology is re-imagining information security.

SAP have got everything in place for you to do this today, and here's the thing, and now, within the SAP Partner Edge Open EcoSystem there are enabling technology Blockchain Products designed and built by SAP Experts specifically for the needs of SAP Customers to make doing Blockchain and SAP easy, and so today, you can do SAP and Blockchain, it's no longer hype, today it's real and there's nothing stopping you.

Reference Architecture Event Driven Blockchain with SAP

Here is an example of how Enterprise Blockchain can be implemented to bring next generation data integrity protection to the Oil and Gas OT to IT integrations.

The Enterprise Blockchain Database Tenant is running at the E&P Sector and at the same time, the Enterprise Blockchain Database Tenant is running at the SAP Business Technology Platform. The OT Data is written to the Enterprise Blockchain Database and the SAP S/4HANA and or SAP Industry Cloud read the data from the same Enterprise Blockchain Database.

SAP Oil and Gas OT to IT Integration Blockchain Security atkrypto.io

As McKinsey & Company, in their December 2023 Featured Insights Publication, gave a beautiful description of what is unique and special about Blockchain, "Blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time".

The good news is, as we discussed in the previous blog, this is no longer hype, we can do all of this today, and now, within the SAP Partner Edge Open EcoSystem there are enabling technology Blockchain Products designed and built by SAP Experts specifically for the needs of SAP Customers to make doing Blockchain and SAP easy, and so you can do SAP and Blockchain, today it's real and there's nothing stopping you.

So what are we waiting for ? Oh yeah, more use cases, ok, that will continue in the next blog

What do you think, are the words Blockchain, Web3, Distributed Ledger Technology, starting to appear in your Company's visions and technology visions ? What use cases are you looking at ? Let's chat about it in the comments.

For now, over and out.

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy Silvey is a 25 years SAP Technology veteran [15 years SAP Basis and 10 years SAP Tech Arch including Tech, Integration, Security, Data from 3.1H to S/4HANA PCE on RISE and the BTP and everything in between, and former SCN Moderator and Mentor alumni].

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

The atkrypto Enterprise Blockchain Platform for SAP has been designed by SAP Independent Experts for the needs of SAP Customers and to be deployed on the SAP BTP Kyma Runtime Service and leverage native integration to SAP Products.

atkrypto Enterprise Blockchain Platform for SAP has a number of unique qualities, including being the only Blockchain software in the world which has a DataCenter version and a light mobile version which can run on Edge/IoT/Mobile devices and enables data to be written to the Blockchain at the Edge where that same Blockchain is running on a Server in the DataCenter, protecting the integrity and originality of data from the Edge to Insights. Taking Blockchain to the Data at the Edge instead of taking the Data to the Blockchain.

A Robust Security Package for the SAP Customer Data Cloud (CIAM)

2024-03-18T17:41:26.395000+01:00

In today’s fast-paced digital sphere, managing customer identities and data has become a significant task for businesses. It has become crucial to have a functional system that can robustly handle user identities, access management, and data privacy.

The SAP Customer Data Cloud (CIAM) – Security Package securely regulates user access and provides a secure environment for customer data.

CIAM comprises an identity management solution that simplifies customer data management. It offers Single Sign-On (SSO), robust registration, and social login options to streamline user experience and boost customer engagement. The data is stored securely, given the strict compliance standards that the software adheres to.

Security Package offers multi-factor authentication, risk-based authentication, and advanced security reporting to safeguard against data fraud. It not only protects sensitive data from potential breaches but also maintains regular auditing to ensure persistent monitoring and control of data access.

Privacy and Consent Management. Compliance is a significant aspect that businesses need to employ diligently. It provides comprehensive regulatory functionality that helps businesses stay compliant with various data protection regulations across the globe. It allows users to conveniently manage their consent preferences, making the business more trustworthy.

To understand the SAP Customer Data Cloud (CIAM) features and functions more deeply, check the blog. It provides a broad perspective on the CIAM security package, how it works, its benefits, and other relevant information.

Overall, the CIAM Security Package provides a reliable security infrastructure that businesses can leverage to secure customer data and enhance customer experience. It’s a well-rounded solution that addresses the critical aspects of identity management, security, and compliance. Security Package offers a significant solution for comprehensive customer identity management - a secure, reliable, and future-proof answer to all identity management needs.

Find out more detail in the CX Value map. Sign up for the SAP Enterprise Support value maps by requesting access to SAP Learning Hub or join the SAP Enterprise Support Value Maps Learning Room if you already have access.

Any questions? Please, contact the Value map team!

Mónica Domingo

Global Topic Owner - SAP Customer Experience Solutions

The What Is... The Why To... The How To... of: ESG & SAP & Enterprise Blockchain 🚀

2024-03-21T15:21:10.356000+01:00

What is ESG ?

ESG is "Environmental, Social, and corporate Governance" and revolves around how well an Organisation is performing across these three pillars. The stronger an Organisation is across these pillars, the higher the Organisation's ESG score or rating will be.

What is an ESG score/rating ? For me it's like when I go on Booking.com or AirBnB to find an apartment or hotel for a family holiday, I am looking for the properties which have the highest rating. This is how it is with ESG, the ESG score shows the Organisation's rating across these dimensions, "Environmental, Social, and corporate Governance", where we would expect, the higher the score, the more we can trust the Organisation.

And ESG is more than that, as @James_Marland describes in the blog Your Ledger is about to go Green the European Union is on a journey bringing legislation and "are going to ask companies to maintain a second set of books, that run in parallel to the traditional ledgers, and that’s a set of books called the Green Ledger".

ESG scoring takes a holistic view of the Organisation:

Holistic View on Sustainability Performance – Example WEF SCM Framework

[thanks to @gunther_rothermel and his ESG Performance Management blog]

For me,

ESG is about Data.

Why to do ESG ?

There are hard reasons and softer reasons, the softer reasons are elaborated in more detail below, but the hard reason for doing ESG, the reason we cannot be avoided, is European legislation, and to repeat, so that we don't miss it, as @James_Marland describes in the blog Your Ledger is about to go Green the European Union is on a journey bringing legislation and "are going to ask companies to maintain a second set of books, that run in parallel to the traditional ledgers, and that’s a set of books called the Green Ledger".

ESG (“Environmental, Social, and corporate Governance”) concerns are playing a greater role in investment decisions and hence corporate decision making.

Part of the ESG framework is scoring Organisations to measure how they are performing against ESG standards.

ESG scoring helps to provide a standardized way to quantify an Organisation’s ESG impact, and is consumed by:

Consumers of ESG Ratings - atkrypto.io

In her blog, @annchristinschechter , the report describes it like this:

The Situation: Sustainable Business is the 3rd Wave of Global Economic Transformation

Investors, shareholders, regulators, and consumers all demand responsibly derived products
and services with a smaller environmental footprint. Reducing global emissions,
waste, and social injustice requires a full-lifecycle approach with enterprises at the forefront.

Wittwer Reichel Knoedler - Sustainability within SAP Premium Engagements

Going back to the, Booking.com or AirBnB to find an apartment or hotel for a family holiday analogy, in the same way as a properties with lower ratings attract less interest, the time will soon be upon us when Organisations with lower ESG scores will be at a disadvantage compared to those with higher scores.

That and social responsibility is Why To Do ESG.

For me, again,

ESG is about the Data, and if the Data is so important, then we need to be able to Trust the Data.

How to do SAP, ESG, and Enterprise Blockchain

The ESG score is an example of the circular economy. The key to the score is the Data, the Data coming from in most cases the Edge, from Sensors and Things. As shown in the picture below, the Data from the Edge needs to be stored safely and securely so that it can be processed by the SAP Sustainability Control Tower:

SAP - ESG - IoT - Enterprise Blockchain - atkrypto.io

SAP by the way, have a portfolio of Products to enable Enterprises to do ESG, and these include:

. SAP Sustainability Footprint Management

. SAP Sustainability Data Exchange

. SAP Sustainability Control Tower

In this blog we are focusing on protecting the integrity and originality and confidentiality of Data which is used to do ESG scoring and rating, Data which would then be consumed by for example the SAP Sustainability Control Tower.

There are two related challenges to overcome when collecting data for ESG scoring. The first comes in two parts: simply collecting the data in the first place, since there may be large numbers of sensors and systems (consider carbon emissions across a supply chain, and the myriad vehicles, vessels, machines and people involved); and moving that data fast enough that decisions can be made using it (which we’ll use as the definition of “real-time” in the rest of this blog)

The second challenge is that with any measurement system, the measurement is only as reliable as the data collected. This opens a “trust gap:” organisations have incentives to increase their ESG score: how can we be sure of the validity of the data they’ve collected? Similarly, how can they be sure of the data their subcontractors have collected?

Investors are increasingly demanding ESG Audits of target Organisations, and it’s likely the requirements of ESG scoring become stricter. Being able to demonstrate that an Organisation’s ESG data collection methods are beyond reproach is likely to represent a significant business advantage, along with benefits of reacting to this data in real time.

ESG Data Sources

ESG measurement data can contain Personal Sensitive and Business Critical information across the Corporate domains of:

ESG Data Sensitivity atkrypto.io

Data sources for this data come from all over the organisation: Enterprise Applications and Things (sensors, monitors and connected applications at the edge), including ERP systems, HR systems, Sensors measuring CO2 levels and Water Quality.

In this blog we’ll take as an example data from Waste Trucks proving responsible disposal of Corporate waste, to see just how many sources of data there are and how to address the challenges this creates.

ESG Example Sources of Data - atkrypto.io

ESG Data Security

In terms of the NIST CIA Triad for Data Security, Criticality, Integrity, Availability, ESG measurement data comes in Very High across all three classifications.

NIST Triad Data Security Sensitivity Confidentiality Integrity Availability - atkrypto.io

As the ESG performance rating is so critical, data measurements which are used need to be auditable and the integrity of the data completely trustworthy, so the highest level of data security and integrity protection is required.

To address the “trust-gap”, it is essential that it can be proven that the ESG measurement data cannot be interfered with and can be trusted. At the same time, the ESG measurement data needs to be available to a number of Enterprise Applications for it to make any actionable change.

Enterprise Architecture saves the day...

So, this is where Enterprise IT comes in to save the day and solve the problem.

The business requirement is for:

. Data from any source needs to be Stored as close to the source of the Data as possible

. The source of the Data can be Edge / IoT / Mobile Things, and can also be ERP and Enterprise Software Applications

. The Data needs to be stored with the highest level of integrity and originality and confidentiality and sensitivity protection

. The Data store solution should be available out of the box in a commercial off the shelf product

. The Data must be stored Immutably

As discussed in the previous blog, [SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀] when we look in to our Enterprise Architecture Technology Standards we see there is only 1 Technology Standard in the Enterprise which is positioned with the capabilities to fulfill all of those requirements out of the box, and that is the, Enterprise Blockchain Platform and Enterprise Blockchain Databases.

Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

Why Enterprise Blockchain Database for securely storing ESG measurement data ?

As we described in the first blog in this series, [Why I love SAP and Blockchain Databases and why you should too 🚀], there are four characteristics which make Blockchain natively the most secure data storage.

These are:

atkrypto.io what is a blockchain

A Blockchain can only be called a Blockchain if it has these characteristics, the point being that once data is entered in a blockchain it cannot be altered or deleted. This provides trust in the data, so that, for instance, ESG auditors know that if a measurement is calculated from data held in a Blockchain, they can trust that the data hasn’t been adulterated while being stored.

In the following Enterprise Blockchain Platform for ESG deployment example scenarios we have data coming from multiple data sources, some of which are at the Edge/IoT and some are Enterprise Applications in the DataCenter or Cloud. At the same time data which is being written to the Enterprise Blockchain Database can originate from multiple Organisations which are sharing the same Enterprise Blockchain Platform and Database as a common shared single source of truth.

ESG Comparison Enterprise Blockchain Database and Traditional Legacy Database - atkrypto.io

The immutability of blockchain data is what enables trust between what otherwise might be competing organisations.

Example 1, Single Enterprise Blockchain Database within your Organisation for ESG Data

In this example, an Enterprise is storing ESG data to its Enterprise Blockchain Platform.

ESG data is originating from multiple sources as shown in the diagram:

ESG Example Sources of Data - atkrypto.io

Imagine an Enterprise subcontracting the disposal of its electronic waste. For ESG compliance the Enterprise needs to make sure that its waste carrying vehicles aren’t tempted to take short cuts in personnel management or the disposal, but must also verify the subcontractor is upholding their standards, too.

Data can be used from the Waste Truck’s GPS and onboard cameras to prove both where the waste was disposed of geographically through the GPS data and physically through the photographic evidence from the Truck’s on board cameras. Think about how delivery drivers photograph where they’ve left a parcel.

The collection of this data is enabled either by SAP Advanced Event Mesh, which spans geographies and environments such as On-Premise, Cloud and all the way to the Edge, connecting the Waste Truck to Enterprise Applications such as Route Planning, HR management, Scheduling and other operational systems as well as the Enterprise Blockchain Database Edge Tenants and the Enterprise Blockchain Database Server Tenants.

All this data, including the photographs, are stored on the Enterprise Blockchain Platform Database, the photographs will be stored as Enterprise NFT’s in the Enterprise Blockchain Wallet.

Next generation data integrity protection is Enterprise Blockchain Platform on SAP BTP Kyma - the secure data backbone - atkrypto.io

Example 2, Single Blockchain shared across Organisations for ESG Data

This example is where the real beauty of the Distributed Ledger Technology is brought in to focus.

Enterprise Blockchain Platform Database as a shared single source of truth across Organisations.

In this example the Enterprise Blockchain Platform is running Blockchain Database Tenants in your Organisation and also in your Partner Organisations. This enables the Enterprise Blockchain Database to provide an irrefutable shared single source of truth for data across Organisations, who normally would not openly trust each other with data.

ESG Data from 3rd Party Organisations Enterprise Blockchain Shared Common Single Source of Truth - atkrypto.io

Your Organisation outsources industrial waste collection and responsible disposal to a 3rd party Organisation.

Your ERP system orders the 3rd Party Waste Processor to collect and dispose of industrial waste.

For your Organisation’s ESG data, you depend upon evidence that the 3rd Party Organisation is responsibly disposing of the waste.

The Enterprise Blockchain Platform Database enables a shared single source of truth to be created across the Organisations by running inter-connected Blockchain Server Nodes in both Organisations.

SAP ESG Blockchain Shared Single Source of Truth across 3rd Party Organisations - atkrypto.io

In the above example, the Enterprise Blockchain Platform Database is running across Organisations.

Your Organisation is writing data to the same Enterprise Blockchain Database as your 3rd Party partner Organisation.

The Enterprise Blockchain Database contains evidence from your S/4HANA ERP system that the 3rd Party Waste Processor was ordered to process your industrial waste.

In the same Enterprise Blockchain Database the 3rd Party Waste Disposal Organisation is storing evidence from the Waste Trucks that the waste was collected from your premises and disposed of responsibly at the authorised waste treatment center.

This scenario opens a new world of opportunities for multiple Enterprises to share data, multi-Enterprise collaboration, with the Enterprise Blockchain as the irrefutable common shared single source of truth across Organisations.

The most beautiful thing about the picture above is that we have an Enterprise Blockchain Database shared across 3rd party Organisations, this achieves a few things:

. Saves a huge amount of effort to integrate the IT systems of the two 3rd party Organisations

. Enables both Organisations to write Data to the same Enterprise Blockchain Database

. Enables both the ESG Customer Organisation to read the Data from the Enterprise Blockchain Database into their SAP Sustainability Control Tower to enable ESG Reporting

. Enables both Organisations to be able to trust the Data in the Enterprise Blockchain Database

. Enables both Organisations to know that neither Organisation can modify the Data in the Enterprise Blockchain Database

. Enables both Organisations to know that their shared Data is being protected to the highest level natively out of the box of any Database Product

Wrapping Up

To wrap up, a simple reminder,

The Digital Transformation of Information Security is Enterprise Blockchain

Enterprise Blockchain is the Next Generation Data Integrity, Originality, Confidentiality Protection

Enterprise Blockchain, Enterprise Distributed Ledger Technology is re-imagining information security

With regards to ESG,

ESG is about Data

ESG is about the Data, and if the Data is so important, then we need to be able to Trust the Data

If we need to be able to Trust the Data, then we need to put it on to the Enterprise Blockchain as the irrefutable common shared single source of truth across our Organisation and other Organisations

Enterprise Blockchain is both a Secure Store and a Secure Communication Channel.

This blog is the fifth in the series, the previous blogs are here, here, here and here.

We will be describing more use cases for this scenario in future blogs, including for example the Insurance use case, where the Carrier, the Broker, and the Customer are on the same Enterprise Blockchain.

So what are we waiting for ? Oh yeah, more use cases, ok, that will continue in the next blog

Credits: Tom Fairbairn Distinguished Engineer at Solace contributed to this blog. We will be following this blog up with a deeper Technical Architecture dive into getting the Data and how SAP Advanced Event Mesh is positioned in the Solution Architecture for publishing the real time ESG Data and Enterprise Blockchain is positioned for Protecting the ESG Data, Event Driven Blockchain, Publish & Protect.

For now, over and out. 🚀

Andy Silvey.

Independent SAP Technical Architect and CEO of atkrypto.io

Author Bio:

Andy is also co-Founder of atkrypto inc, an startup whose ambition is to make Blockchain easy for Enterprise.

atkrypto.io's flagship product is the atkrypto Enterprise Blockchain Platform for SAP, and atkrypto.io is a SAP Partner Edge Open EcoSystem Partner.

SAP Mobile Start V1.11 - Release Update

2024-03-25T09:47:10.630000+01:00

With the latest release of SAP Mobile Start, you get some nice features for end users, and also for administrators. Further more, we support a new language: Turkish.

Before we go into the new app features, I want to mention a new content type that we support with SAP Mobile Start: SAP Analytics Cloud KPIs as monitoring tiles and widgets. Now, you can see your SAP Analytics Cloud business KPIs in SAP Mobile Start as well. The KPIs are shown on the respective tile or widget, and you can easily navigate to the details (analytical story) by tapping on them. Based on the configuration, analytical stories can be opened within the native SAP Analytics Cloud app or within the embedded web view of SAP Mobile Start.

SAP Mobile Start – SAP Analytics Cloud KPIs

Please check my latest blog Content is Key – SAP Mobile Start now supports SAP Analytics Cloud KPIs on Tiles & Widgets.

Now, let´s have a look at the new features. With the latest release, you can now search/ filter the list of your to-dos for faster access to the respective tasks or SAP S/4HANA situations.

Search and Filter for To-Dos

You also can share your to-dos with your colleagues now, for instance a SAP S/4HANA situation. Just tab on the action menu of a to-do and select share. Then you can chose from the standard device sharing options how to share it.

Sharing of To-Dos for easy collaboration

With the new release, system administrators can apply additional settings in the Mobile Settings Exchange menu of SAP Mobile Services:

Require to passcode-protect the watch before being able to use SAP Mobile Start on it
Disable the download or upload of files (like attachments) from the app, via the embedded web-view

SAP Mobile Services - New features

I hope you like this new feature within SAP Mobile Start, we will certainly continue to add more attractive content types.

For further information on the new topics, please check our SAP Mobile Start documentation.

SAP Mobile Experience offers intelligent native mobile solutions that help businesses build more efficient, resilient and sustainable end-to-end processes, improving people’s work life wherever they are.

Visit SAP Mobile Experience Community Page and click “follow” to get the latest development and innovation of our solutions. We look forward to hearing about your experience with setting up the solution in your landscape; please do share your thoughts and comments below. Enter here for additional questions regarding SAP Mobile Experience Applications.

Want to be notified? Check your profile settings to ensure you have your settings activated.

SAP IdM migration guidelines to help you on your upcoming IAM journey

2024-03-25T14:21:37.058000+01:00

Let me introduce to you the ROIABLE SAP IdM Migration Guidelines. Your one-stop information guide on important features, concepts and technicalities around an SAP IdM migration. With 94 topics covered, the guide encapsulates 15 years’ experience of SAP IdM implementations, operations, and enterprise support.

The content is future product agnostic, meaning you should be able to apply the explained concepts to any selected IAM of choice. Surely some will have advantages over others in certain areas, but using the above comprehensive guide, you will, at least, be able to ask all the right questions, when it comes to selecting the successor of SAP IdM.

Each topic is structured similarly, color-coded based on the category which it fits. The top left part is reserved for its number, name, and abbreviation. On the left, you can find a summary of its usage within the scope of SAP IdM, while on the right is a recommendation of how this particular topic should be migrated or not onto your future IAM platform. At the bottom you can find related topics to continue browsing the document or respectively return to the overview slide using the home button.

The various topics covered spread over 10 categories, which only shows the wide diversity to be considered when taking care of your SAP IdM migration. The document is still work in progress, but there are already released topics, which you can find here.

Stay tuned for the full release and its respective announcement. Till then, make sure to check the link above regularly for newly uploaded content.

Retain investment, stay compliant and embrace the cloud!

Security in SAP Analytics Cloud, free learning journey

2024-03-25T17:37:27.137000+01:00

For those who still haven't put the topic of security on their company's daily agenda, I recommend to have a look at Deloitte`s Global Future of Cyber Survey report.

Interesting (but not surprising) fact is that executives see cyber playing a crucial role for all digital transformation priorities, especially when it comes to cloud and data analytics. Data analytics in the cloud, in SAP`s terminology this means the SAP Analytics Cloud.

What is security in SAP Analytics Cloud? In detail, it`s about the understanding of the concepts of SAP Analytics Cloud content security, Creating and Managing users and roles, Securing data, content and objects and Configuring authentication options.

Join our new free Managing Security and Administration in SAP Analytics Cloud learning journey and get basic knowledge and skills required to be able to successfully secure content and data in SAP Analytics Cloud.

SAP Product Learning Coe Analytics Team

SAP Integration Suite – Access Policies for Integration Packages

2024-03-25T18:55:44.335000+01:00

As of increment 2401 of SAP Integration Suite, you can define access policies for integration packages. This extension makes the lives of tenant administrators easier who need to manage large numbers of integration packages and selectively restrict access to integration content for different user groups.

Short reminder of what Access Policies are:

With an access policy, you can protect groups of integration artifacts against undesired access. You define access policies as described in SAP Help Portal under Managing Access Policies | SAP Help Portal.

For example, you can define an access policy for all integration flows that fulfil the condition: name contains the string ‘Read’. As consequence, all integration flows that meet this condition are protected against unauthorized access.

Protection against unauthorized access covers:

All operations on the design time artifacts (such like editing, saving, or deploying an artifact, for example)
All operations on the deployed runtime artifacts (like restarting an artifact, for example)
Data that is processed or stored by the artifacts (like business data stored for monitoring purposes or stored by integration flows in local data stores or variables)

To enable dedicated users to access these protected artifacts, a role needs to be defined in SAP Business Technology Platform (SAP BTP) cockpit that is associated with the access policy (for more information, see the online documentation).

Access policies can be defined for all available integration artifact types such like integration flows, value mappings, and so forth.

Back to the new feature introduced with increment 2401.

When you open the access policy screen in the Monitor > Integrations and APIs section of SAP Integration Suite (Access Policies tile), you now notice that you can also select Integration Package as Type:

Using this new option, you only need to specify one single artifact reference to protect all artifacts of an integration package. In the example above, an artifact reference for the integration package with the name My First Integration Package is defined.

You now also understand to what extent the extension makes the life of the tenant administrator easier, whom we talked about earlier:

If you like to protect all artifacts in a dedicated integration package, you can now define an access policy with one single artifact reference. Before this enhancement, you needed to create an individual artifact references for each integration artifact type separately.

Use Cases

You may be wondering in which cases it makes sense to define access policies for integration packages. Let me point out the following rule of thumb:

Option	Use Case
Define access policy for an integration package …	If you like to protect all the artifacts of an integration package (including artifacts of all types).
Define access policy for individual artifact types (for example, integration flows and value mappings) …	If you like to protect only few, but not all artifacts of the integration package.

Compatibility with Access Policies for Specific Artifact Types

As said, an access policy for an integration package affects the access to all artifact types contained in the package. However, you can still define access policies for individual artifact types. Now the following can happen: you may want to define an access policy for a specific integration package that contains artifacts for which other, artifact type-specific access policies exist already. What happens in such a case? The message at the top of the dialog provides a clue: for compatibility reasons, existing access policies for individual artifact types will remain intact when you define an access policy for an integration package. Access policies for dedicated artifact types co-exist with access policies on integration package level. Or, phrased differently: When you define an access policy for an integration package that contains artifacts that are also protected by another access policy (for example, by an access policy for a specific group of integration flows), the latter remain valid as well. The message prompts you to check if access policies have already been defined for specific artifacts in your package that you want to protect as a whole.

Let's see how the co-existence of access policies on integration package and on artifact level affects things in a specific example.

Let’s assume that an integration package is protected by one access policy. Furthermore, this integration package contains an integration flow that is protected by another access policy.

To walk you through the example step-by-step, the following two access policies are defined:

Access Policy Name	Protects
PackageAccess	Artifacts contained in the integration package with the name My First Integration Package
FlowAccess	Integration flows (across all integration packages) with a name that starts with the word Read (matches regular expression ^Read.*)

The tenant has two integration packages with the names My First Integration Package and My Second Integration Package. Both packages contain also integration flows protected by the artifact-related access policy (integration flows with a naming starting with Read).

As a result of this setup, the artifacts are now protected as shown in the following figure:

As we said that access policies protect the specified artifacts – unless a user has a role assigned that is associated with the access policy – we can do the combinatorics with 4 fictitious users with different role assignments:

User	Assigned role	Role associated with access policy*	Can access
User1	Role1 Role2	PackageAccess FlowAccess	All artifacts in all shown integration packages
User2	Role1	PackageAccess	In the package My First Integration Package protected by the package-level access policy: All artifacts In the non-protected package My Second Integration Package: all artifacts, unless they are protected by access policy FlowAccess (for which this user has no corresponding role assignment)
User3	Role2	FlowAccess	In the package My First Integration Package protected by the package-level access policy: integration flows that are protected by the access policy FlowAccess. All other artifacts are protected from this user through the package-level access policy PackageAccess. In the non-protected package My Second Integration Package: All artifacts (because here, this user also can access the artifacts protected by the integration flow-related access policy FlowAccess)
User4	(No role assigned)	n.a.	Because this user does not have either of the roles, they are subject to the access restrictions defined by both access policies. As a result, the only artifact they can access is the artifact that is covered by none of the access policies (the non-protected integration flow in the non-protected integration package).

*To be more precise: Role associated with an access policy means: For the Values attribute of the role a string is specified that matches the name of the access policy. For more information on this, check out the online documentation in SAP Help Portal under Creating Custom Roles for Access Policies | SAP Help Portal.

SAP Enterprise Support Highlights Resources to Achieve a Clean Core

2024-03-27T17:51:06.351000+01:00

“Clean core. . . to sum it up is the one key puzzle piece . . . to be an agile intelligent enterprise.”

- Markus Albrecht, Adoption Services Center General Manager for SAP BTP

Changing business processes over several months isn’t good enough anymore. There’s now heightened focus on the concept of 'clean core ERP,' signaling the demand for software that’s both robust and agile enough to quickly adapt to evolving needs. However, in today's fast-evolving business landscape, organizations struggle to maintain agility and innovation speed for system upgrades. How can you overcome this significant challenge? How can you benefit from the latest innovations with minimal effort? The answer is by implementing a more standardized, process oriented approach for system updates and this is where a clean core strategy becomes vital.

In SAP Enterprise Support, we provide expert guidance to implement a clean core strategy, helping you become agile, future-proof, and competitive. We've compiled resources to assist you. But before diving into those, let's briefly recap what clean core entails.

Clean Core Explained

According to Markus Albrecht, Adoption Services Center General Manager for SAP BTP, SAP customers across various industries, whether in retail or high-tech, must have the ability to adjust, react, and swiftly switch business models. A clean core offers two primary benefits in this context: it enables faster innovation within an SAP-centric landscape. Once you've adopted a clean core mindset, this approach can also be extended to non-SAP-centric landscape components as well (see LinkedIn post).

So, call it an initiative, a concept, a strategy or an approach, clean core focuses on keeping an organization’s core ERP systems transparent, flexible, consistent, efficient, and cloud-compliant, so they can easily transition to the cloud. The core describes the main aspects of an ERP system, including extensibility, processes, data integration, and operation.

A clean core describes an up-to-date IT system with the latest releases, cloud-compliant extensions and integrations, with optimal primary data quality and process design.

Following a clean core strategy means reducing process inconsistencies, establishing governance structures, maximizing standard functionality, building cloud-compliant extensions which are integrated through stable interfaces, and minimizing complex customization.

A clean core approach makes it easy for organizations to upgrade more cost-effectively and with lower potential risk.

SAP Enterprise Support Value Maps Can Help Get You There

Every SAP cloud subscription includes SAP Enterprise Support - a comprehensive digital support experience - and SAP Enterprise Support value maps is your gateway to guided enablement.

With you in mind, value maps provide structured self-paced learnings to advance your digital skills; access to collaborative forums and SAP experts for personalized guidance; and continuous quality checks to mitigate implementation risks or identify optimization potential.

Our new clean core page within SAP Enterprise Support value maps highlights specific offerings designed to support your clean core strategy across the main elements of an ERP system, including business processes, extensibility, data integration, and operations. For instance, take a look at the resources available* for SAP Business Technology Platform:

*This represents the current situation, with new resources continuously added.

In addition to SAP Business Technology Platform, we have also gathered the relevant SAP Enterprise Support offerings to achieve a cleaner core in:

SAP S/4HANA
SAP S/4HANA Cloud Private Edition
Data Volume Management
SAP Signavio | Business Process Transformation
Business Process Improvement
Security

Where to Access

3 Easy Steps:

One-time sign-up for SAP Learning Hub, edition for SAP Enterprise Support, is required
Access value maps
Navigate to the clean core page within value maps learning room

When you're in the value map, feel free to join our forums, ask questions, or "Request a Call" to speak with one of our experts for more assistance. Value maps are easy to use, but a call with us helps us customize the conversation to your needs and point out relevant content.

Explore how implementing a clean core strategy can elevate your business process applications across your organization, and maximize the efficiency of your current software. Visit value maps today to learn more.

Got a question about the value maps, or our content?
Leverage the “ask questions” feature in the value map or contact us:
sapesvaluemaps@sap.com

References

Conversation with Markus Albrecht, Adoption Services Center General Manager for SAP BTP (LinkedIn post)

The Value of Clean Core (LinkedIn post)

Further Information

Clean core (SAP website)

Beyond Basic (1): Certificate-Based Authentication

2024-04-05T17:53:02.875000+02:00

The topic of certificates is a confusing one. This text is the attempt to explain the why and how of certificate-based authentication and the difference between client certificates and server certificates. While Bob and Alice make an appearance in disguise, we try to keep the technical parts simple and only assume that the reader knows the general mechanism of asymmetric cryptography (using a key pair such that text encrypted with the one key can only be decrypted with the other).
This blog post tries to provide some background for a second text that talks about the specifics of connecting to SAP S/4HANA Cloud Public Edition using authentication with client certificates.

Why Certificate-Based Authentication?

With traditional basic authentication, credentials (username and password) must be known to both the client and the server for authentication. This means that the secret password must be securely distributed to the client and server in some way.

With certificate-based authentication (also called X.509 after a format for certificate files, or mTLS after a protocol implementing certificate-based authentication), the client only presents a certificate that is then verified by the server. In this asymmetric authentication, only the client keeps a secret, the server only uses public information to verify that the client is in possession of the secret. This means that no exchange of secrets is required beforehand and fewer parties need to keep secrets.

And this is just one of multiple advantages of certificates over passwords. Certificate-based authentication is a de-facto standard for system-to-system communication in security-aware organizations and a general best practice.

What is a Client Certificate?

In essence, a client certificate is a public key (in the sense of asymmetric cryptography) that is signed by a trusted certificate authority (CA) and for which the client holds the corresponding private key.
"Trusted" in this context means that the system we want to connect to believes that the signing CA has sufficiently verified our identity before signing the key.

As an example, the CAs that SAP S/4HANA Cloud Public Edition trusts are listed in SAP Note 2801396. Only client certificates with signatures by one of these CAs will be accepted by the system for authentication. In particular, self-signed certificates or certificates signed by company-internal CAs are not accepted.

And What is a Signature?

Cryptographic signatures are not restricted to certificates. They are a means for verifying the integrity and authenticity of messages in general.
In very broad terms, this is how a signature works: a message is sent through a hash algorithm to produce a unique (ok, "reasonably unique" for mathematicians) fixed-length string. That hash value is then encrypted with the private key of an asymmetric key pair. The resulting ciphertext is the signature of the original message.

And how does the signature guarantee the integrity of the message? The signature is sent together with the message, so the receiver of the message can decrypt the signature using the public key of the asymmetric key pair and compare it to the hash of the message (the hash function is public knowledge). If hash value and decrypted signature are the same, the message is intact. If they don't agree, either the message or the signature was changed. In either case, the message can't be trusted to come from the owner of the public/private key pair. And because only the holder of the private key can create the signature, a valid signature also guarantees authenticity of the message.

In the certificate case, our public key is the message: The CA takes our public key, appends some metadata (the subject, expiry date, issuer identification...) and hashes it. Then the hash is encrypted with the CA's private key. The result is our certificate: a public key plus metadata plus signature by the CA. By slight abuse of notation, we say that the CA certificate signs our certificate, while it's really the private key belonging to the CA certificate that does the signing.

Creation of a certificate from public key and metadata by a CA

Validating the signature means that the receiver of our certificate calculates the hash of the public key (including metadata) and decrypts the signature using the public key of the CA (the CA's certificate). If the decrypted signature and the hash are the same, our certificate is valid and has not been tampered with.

Validation of certificate integrity

How Does That Authenticate a Client?

To the server, authenticating clients are just users. When a client authenticates, that means that the corresponding user logs on to the system.
To be able to identify and authenticate a user, the user is assigned a unique certificate – just as the user would have a unique name/password pair for basic authentication. The certificate is not a secret, though, it's just a public key. We can interpret this mapping as "anybody who has the private key for this public key will be treated as this user" (just as anybody knowing the right name/password combination would in basic authentication).

Server trusting CA and verifying client certificate

The certificate-based authentication flow can be thought of like this:

the client hands over its client certificate (which contains the client's public key) to the server
the server verifies that the certificate is signed by a trusted CA (i.e., the CA certificate is in the server's list of trusted certificates)
the server encrypts a random message with the public key from the client certificate and sends it back to the client
the client decrypts the encrypted message (using the private key) and sends the plaintext back. Now the server knows that the client has the private key of the certificate
the server looks up which user has the certificate assigned – that user is successfully authenticated

Challenge-response protocol for authentication based on client certificate

While that's not exactly what happens, it hopefully conveys the general idea.

A few side remarks:

In the authentication flow outlined above, no secrets are exchanged. This is a major security benefit. The idea of the challenge-response protocol is that the server presents the client with a task that can only be solved if the client has the private key. If the client solves the task, the server is confident that the client must have the key – without being shown the key itself (this is sometimes called a zero-knowledge proof).
It might sound like magic, but it's really just very clever mathematics.
The statement "the user is assigned a unique certificate" is not completely correct. In fact, only the issuer and subject of the certificate are mapped to the user, not the entire public key.
This is made possible by the trust relationship between server and CA: The server trusts that the CA checked that the owner of the private key is sufficiently identified in the certificate's metadata already. So, the server trusts the metadata in the certificate rather than demanding an exact public key match.
This has a big advantage: when the client certificate expires, we can exchange it for a new one with the same subject and issuer without having to re-upload it to the system.
As already mentioned in the introduction, this setup does not involve exchange of secrets. No password has to be given to the server administrator to configure the connection. And certificate rotation is a one-sided process that does not require simultaneous changes on client and server side (as password rotation does).
If the server is hacked, no secret credentials can be stolen. This means that the "no password reuse!" imperative does not apply to certificates. We can use our client certificate to authenticate to multiple systems (and we actually do in SSO setups).

Client Certificate, Server Certificate – What's the Difference?

Technically, client certificates and server certificates are the same thing. The difference is in the usage of the certificate. Let's have a look at what happens when a client calls a server (in the TLS handshake that also happens when a browser calls a website):

the client asks the server to establish a connection
the server hands over its public key (the server certificate) to the client
the client verifies that the certificate is signed by a CA it trusts
the client verifies that the server is in possession of the private key of the certificate
the connection is established

Again, that's not exactly how the TLS handshake works, but it's close enough as a mental model.

Client trusting CA and verifying server certificate

And yes, that's the same thing that happens as above (section "How Does That Authenticate a Client"), with the roles of client and server interchanged. In the TLS handshake, the server authenticates against the client. Note that at the end of this flow, the client has assurance as to the identity of the server, but the server knows nothing about the client's identity.

But where does the trust in the CA come from? Clients maintain a list of trusted CAs. And often client software is shipped with a pre-configured list. Operating systems also maintain a list of trusted certificates that is pre-populated by the vendor.

And where's the user-certificate mapping? It's implicit: the server's "username" is the host name. The server certificate's subject attribute says "this certificate is issued for example.com". So, if the client calls the server example.com and is shown a valid certificate issued for example.com by a trustworthy CA (and the server proved that it has the private key), the client can be sure it's really talking to the right server and not some man-in-the-middle. In browsers, successful verification is shown by a padlock icon next to the URL.

Browser showing message about successful validation of server certificate

How do the Two Come Together?

When we log on to the system, the client first authenticates the server to establish a connection: The client verifies that it's talking to the real server by checking the server certificate (server's name is in the "Common Name" or "Subject Alternative Names" of the certificate, the signing CA is trusted, certificate has not expired, and the server has the certificate's private key).

In a second step, the server might (or might not as in the case of public websites) authenticate the client/user.

The server's authentication against the client is always using certificates, while clients/users might authenticate against the server using different methods (certificate, basic authentication, token...).

Fun fact: if server1 does a technical call to server2, then server1 presents a client certificate to server2 (because server1 is the caller and hence assumes the client role in this communication). And server2 presents a server certificate to server1. The notation is a bit of a mess…

Aside: Root Keys, PKIs, Validity

Root Keys and the Chain of Trust

As seen above, a valid certificate is one that is signed by a trusted CA. More precisely, it's signed by the certificate of a CA (a signing certificate). That signing certificate in turn is signed by another of the CA's certificates, the root certificate.

Browsers and other clients often trust the CA's root certificate rather than the individual signing certificates. This makes certificate validation a multi-step process but reduces the number of trusted certificates.

Chain of certificates: root certificate, signing certificate, client certificate

Public Key Infrastructure

This setup of root certificates, signing certificates and trusted issuers is part of the Public Key Infrastructure (PKI). The fundamental assumption of this infrastructure is, that there are a few (quite a few, in fact) trustworthy institutions that will dutifully do the identification of servers and individuals so that everybody else can trust the certificates issued as a result of this identification. These trusted institutions are the CAs and their associated registration authorities (which verify certificate applicants – potentially even by inspecting physical documents). All this is pretty similar to the infrastructure for passports in the real world.

Local PKIs/CAs

Anybody can create a CA, of course – the question is just "who will trust it?". It is not uncommon for companies to maintain a company-internal CA that is only trusted by the company's own servers/clients/users. The CA will issue server certificates for internal applications, client certificates for system-to-system communication, and SSO certificates for users (also a kind of client certificate). All this works if the company-CA's root certificate is trusted by all involved parties (it might be provisioned to all computers with the base-image, via a device management system, or by manual import into the operating system's certificate trust list). But it does not work for communication to the outside (e.g., towards 3rd party SaaS solutions) because the outside party does not trust the company-internal CA.

Certificate Validity and Rotation

An important aspect of certificates is their validity. Certificates are only valid for a certain period: server certificates often expire after a year, root certificates can live for decades, signing certificates for a few years. Validity is part of the certificate metadata itself and cannot be changed, so the certificate has to be renewed ("rotated") before expiration.
Certificates expire silently, but the effects can be rather spectacular. If a signing certificate expires, all certificates that were ever signed by that signing certificate become invalid. Expired certificates break TLS connections and client authentication – systems don't talk to each other anymore. A forgotten certificate can turn into a very expensive and difficult exercise.

Up Next: How to Actually Use Client Certificates in SAP S/4HANA Cloud Public Edition

Now that we got some of the basics covered, it's time to look at an example.

In a follow-up blog post, we will see how to create a client certificate and how to use it for authenticating against an SAP S/4HANA Cloud Public Edition system.

The scenario will be like that: we configure SAP S/4HANA Cloud Public Edition to expose an API (an "inbound" communication arrangement) that we will call with a technical communication user. And that user authenticates using a client certificate.

But all this is the topic of the next blog post.

Beyond Basic (2): Certificate-Based Authentication in SAP S/4HANA Cloud Public Edition

2024-04-05T17:53:13.073000+02:00

In a previous blog post, we discussed the use of certificates for authenticating clients and servers in general. Now it's time to see how all this theory works in the real world.

In this tutorial, we will see how to call a technical API exposed by an SAP S/4HANA Cloud Public Edition system with certificate-based authentication. In practice, such calls are typically made by a remote system. To keep things simple, we just use an API client and a command-line tool for demonstration.

Note that this text is only about technical connections with communication users (API users), not about business users (UI users). More on communication management in SAP S/4HANA Cloud Public Edition can be found in the official documentation.

To set up certificate-based authentication, we'll have to do some things on the server side and some on the client side. Here's our plan:

create a client certificate
create a "communication user" in SAP S/4HANA Cloud and upload our client certificate for the communication user to be used during authentication of inbound connections
create a "communication system" in the SAP S/4HANA Cloud Public Edition backend
create a "communication arrangement" (the API to be exposed) in SAP S/4HANA Cloud and map the communication system and -user to it
try it out in some client software

Step One: Get a Client Certificate

This tutorial uses command-line tools available in linux (or the Windows Subsystem for Linux) for the required cryptographic operations.

Create the Private Key and Signing Request

The following command creates a new asymmetric key pair. The private key is written to the file key.pem and the public key is written to the key-signing request csr.pem. The key file can optionally be encrypted with a password.
In addition to the public key, the signing request contains the metadata (the subject) we want to have in our certificate.

openssl req -sha256 -newkey rsa:4096 -nodes -keyout key.pem -out csr.pem -subj "/C=<country>/O=<org>/CN=<hostname>"

The signing request will be sent to a certificate authority (CA) which then signs the public key (including metadata) to turn it into a certificate.

The format of the -subj parameter depends on the CA. The CA only signs certificates with particular subjects (remember that by signing, the CA confirms that the subject correctly identifies us or our host). Which subjects are allowed and what validations have to be passed depends on the CA.

Creation of a key pair

Result: a private key key.pem and a certificate signing request csr.pem.
Note: key.pem contains our private key. This is a secret and must not be shared with anyone!

Get the Certificate Signed by the CA

To get our public key signed to turn it into a "good" certificate, we take the csr.pem file to our CA (one of the approved ones from SAP Note 2801396) and ask for a signature. How this works depends on the specific CA. Often, there's a web UI where you upload the signing request and provide proof that the subject line identifies you or a machine owned by you.

The format for the certificate should be .pem and include the full chain of certificates. If the CA does not support .pem format including the full chain, we take PKCS#7-format and convert the file in the next step.

Result: a certificate file cert2.pem or certificatePKCS7.p7b.

Convert PKCS#7 Certificate to .pem Format if Needed

To be accepted by SAP S/4HANA Cloud Private Edition, the client certificate needs to include the full signature chain and be in pem format. If our CA only delivered a PKCS#7 file, we convert it like this:

openssl pkcs7 -print_certs -in certificatePKCS7.p7b -out cert2.pem

The resulting file should look like a list of certificates with human-readable headers in between.

Certificate chain in .pem format

Result: the converted certificate file cert2.pem

This is the certificate file we need to pass during authentication. It can also be uploaded to the system to be mapped to a user for identification. That's what we will do now. So, let's head over to configure our SAP S/4HANA Cloud Public Edition system.

Step Two: Create a Communication User and Upload the Certificate

In the system, we first create a communication user and upload our certificate (app "Maintain Communication Users"). For the user mapping, a .pem file is required. In contrast to the actual authentication, it does not matter here, whether the .pem file contains the full chain of certificates or just the client certificate alone.

Creation of communication user, upload of certificate

The subject and issuer of the certificate are shown in the UI after upload.

Client certificate in communication user maintenance UI

Step Three: Reference the Communication User in a Communication System

The communication user must then be assigned to a communication system (app "Communication Systems"), so we also create one of those and reference the new user as one for inbound communication.

Communication system with inbound user and certificate authentication

Step Four: Reference Communication System and -User in a Communication Arrangement

Finally, we decide on the API we want to expose (app "Communication Arrangements"). In our example, we'll take the one for change documents of business roles (corresponding communication scenario: SAP_COM_0366). But this is not important – it's the same for all communication scenarios that have an inbound communication channel supporting certificate-based authentication.

We assign the communication system created before and select our user for inbound communication with authentication method "SSL Client Certificate".

Communication Arrangement. Highlighted: system, user, API endpoint

Sep Five: Try it Out

To see that everything worked, we use our client certificate to call the API endpoint (the service URL displayed in the communication arrangement UI). We try this in two clients: the UI-based API client bruno (which is similar to postman) and the command-line client cURL.

Call Using Bruno

In bruno, client certificates are maintained per collection.

We select the certificate file cert2.pem (the one including the full key chain from step one) and the key file key.pem and add it. As "Domain", we take the host name of the system we want to connect to. If we chose to protect the private key by password, that password must be entered here.

Certificate, private key configuration in the bruno API client

Note that we need to give bruno access to our private key key.pem because the client needs to have access to the secret for authentication. But the private key stays with the client and will not be sent to the server.

In case TLS certificate validation is switched on in the global preferences, we might need to additionally upload the server's CA certificate to bruno (see below).

Call Using cURL

The cURL command line looks like this:

curl --request GET --key key.pem --cert cert2.pem --url https://<S4_host>/sap/opu/odata/sap/APS_IAM_API_BROLE_CDOC/BusinessRoleChanges

A CA certificate for validating the server's certificate can be passed with the --cacert parameter (read on to learn how to get the CA cert). To suppress checking of the server certificate for testing, we can use the --insecure switch.

Do we Trust the Server? How to Get the CA Certificate?

The previous steps assume that the client (bruno or cURL) is able to validate the server's certificate during the TLS handshake. That only works if the client trusts the CA that signed the server certificate. If the client does not use the operating system's certificate store or the server's CA certificate is not in the certificate store, we will need to establish that trust ourselves.

To check if our client trusts the server, we can do an unauthenticated call to see the response:

curl --request GET --url https://<S4_host>/sap/opu/odata/sap/APS_IAM_API_BROLE_CDOC/BusinessRoleChanges

If the result is an http code 401, the TLS handshake worked (the client trusts the server, but the server requests authentication). An http-level error indicates a failed certificate check.

The same test works in bruno. We just need to remove the client certificate from the collection (or create a second collection without certificate) to call unauthenticated.

If the handshake doesn't work, we need to make our client trust the CA root certificate that signed the server certificate (for almost all SAP S/4HANA Cloud Public Edition systems, that's “DigiCert Global Root G2”). This certificate can be downloaded from the CA. The server certificate can also be seen in a web browser (after logging on to the system) where it can be downloaded directly. Here are some screenshots from Firefox as an example:

Steps to get server certificate from Firefox UI

This certificate can then be used in bruno as a "custom CA Certificate" or passed to cURL using the --cacert parameter.

Certificate verification and CA certificate setting in bruno

What we Achieved

When everything worked, we have a client that trusts the CA that signed the server certificate of SAP S/4HANA Cloud Public Edition.
This enables a secure communication channel.

We have a communication user that is mapped to the desired API's communication arrangement. This authorizes the technical user to do calls against the API.

We have a client certificate that is signed by a CA that SAP S/4HANA Cloud trusts.
This enables us to authenticate against SAP S/4HANA Cloud with this certificate.

And we have our client certificate mapped to the communication user.
This enables us to authenticate as this particular communication user and ultimately get data.

The CAs signing the server and client certificates might of course be different ones, so we show them with different names in the final picture of this blog post.

Client and SAP S/4HANA Cloud: trust relationships and verifications during mutual authentication

SAP Secure Login Service for SAP GUI Now Supports Custom Certificate Authorities on AWS

2024-04-11T10:24:50.174000+02:00

The SAP Secure Login Service for SAP GUI solution provides your SAP GUI users with simple and secure access to their ABAP-based business applications. In March 2024, we released the long-awaited Custom Certificate Authority (CA) feature. You can now integrate your own Public Key Infrastructure (PKI) by connecting to a private CA hosted on Amazon Web Services (AWS).

With the SAP Secure Login Service for SAP GUI, you can provide end users of SAP GUI with X.509 certificates that enable single sign-on (SSO) to ABAP-based business applications. After successful authentication, the SAP Secure Login Service provisions a short-lived X.509 certificate to the Secure Login Client on the end-user desktop. This certificate is then used for SSO to the ABAP systems. In the initial scope of the solution, the SAP-managed Cloud CA was used to sign these end user certificates.

What’s new?

With the newly released feature you now have the option to integrate your own PKI by connecting your cloud-based private CA running on Amazon Web Services (AWS) to the SAP Secure Login Service. After successful authentication of the end user, your private CA issues an X.509 certificate. And the SAP Secure Login Service then returns this X.509 certificate to the Secure Login Client on the end user desktop.

How does it work?

By connecting your cloud-based private CA running on AWS, the X.509 certificates will be signed by your own customer-managed CA. The SAP Secure Login Service will just reuse your CA setup and provision the certificates to the Secure Login Client of the end users.

Configuration required for the token exchange, credentials for accessing AWS, and which AWS Private CA to be used can be configured in the administration console of SAP Secure Login Service (via the new tab “Custom CA”). This configuration is needed for secure token exchange and to ensure that only your SAP Secure Login Service subscription can be used to access your custom CA. And at the same time, that the certificates can only be used for SAP GUI SSO.

Of course, the certificates that are signed by your custom CA will look differently from the ones that are signed by the SAP Cloud Root CA. You can decide about the root, how many levels you want to have in there, and the names.

For configuration information, please refer to the documentation that is available on SAP Help Portal here:

https://help.sap.com/docs/SAP%20SECURE%20LOGIN%20SERVICE/c35917ca71e941c5a97a11d2c55dcacd/32875689a8654e0bb3c8697fb6947940.html

What are the benefits?

For compliance reasons you might not be allowed to use the SAP-managed Cloud CA to sign the end user certificates but have to use a CA that is fully under your control. With the new feature you can now integrate with your custom CA running on AWS thereby having full control how the CA is set up. For example, the root of the CA, whether it is in the AWS CA or offline, and how the signed certificates will look like.

More information

For more information about our SAP Secure Login Service for SAP GUI solution and to stay up to date on the latest developments, visit our topic page in SAP Community:

https://pages.community.sap.com/topics/single-sign-on

SAP S/4HANA Cloud Public Edition: Security Configuration APIs

2024-04-19T15:55:22.168000+02:00

Security configuration settings are crucial to run SaaS applications: Are certificates maintained, is CSP enabled, are protection allowlists valid? However, given the ease with which SaaS apps can be deployed by business users, it can quickly become confusing to maintain a good security posture for all of them.

SaaS Security Posture Management (SSPM) solutions help in identifying gaps in configuration settings across all SaaS apps in use.

And that makes SSPM solutions different compared to SIEM and CASB solutions. SIEM (Security Incident and Event Management) solutions analyze logs for suspicious patterns. CASB (Cloud Access Security Broker) solutions can enforce security policies based on user behavior and configuration settings.

With SAP S/4HANA Cloud Public Edition 2402, SAP provides APIs to enable customers to gain insights into their security configuration settings. The available APIs are based on SAP’s security recommendations and cover aspects managed by the customer that might require business decisions, like user and authorization management.

Available Use Cases and APIs for SAP S/4HANA Cloud Public Edition

The following APIs are available with SAP S/4HANA Cloud Public Edition, 2402 under api.sap.com. Potential use cases are listed below to serve as examples.

Business user role/authorization configuration

It is possible to use the following APIs to retrieve business user and role data, e.g. users with important roles. Customers can monitor high-risk roles and role-catalog combinations and limit their usage. The idea is to help monitor critical cases, and not to uncover authorization flaws.

Business User - Read Logon Details (Type: ODATA V4): Read logon details, such as username, validity, group and assigned business roles using this synchronous inbound service.
Business Role - Read (Type: ODATA V4): Read business role details using this synchronous inbound service.

The corresponding SAP Fiori apps to cover this use case are Maintain Business Users (F1303) and Maintain Business Roles (F1492). Further documentation also referenced in our security recommendations can be found in our help portal.

Detection of unused users/connections

The following APIs support the use case to enable customers retrieve an overview of either locked or unused business users. Ideally a definition is available how much time must pass to assess if business users are locked / unused for too long. The same applies for communication users, especially if the communication user is unused for a long time, but assigned to a communication arrangement.

Business User - Read Logon Details (Type: ODATA V4): Read logon details, such as username, validity, group and assigned business roles using this synchronous inbound service.
Communication User - Read (Type: ODATA V4): Read communication user using this synchronous inbound service.

As written before, users can also achieve the same with SAP Fiori app Maintain Business Users (F1303). Regarding communication user maintenance, the suitable SAP Fiori app is Maintain Communication Users (F1338). Our SAP help portal also provides the following information regarding role maintenance and communication management.

Communication settings (authentication methods etc.)

To gain insights into communication settings, the following APIs can be used. Ideally, customers define a policy to determine acceptable combinations of communication arrangements and authentication methods and an identification via API of communication arrangements violating this policy can be established, or communication users used in multiple communication arrangements.

Communication User - Read (Type: ODATA V4): Read communication user using this synchronous inbound service.
Communication System - Read (Type: ODATA V4): Read communication systems using this synchronous inbound service.
Communication Arrangement - Read (Type: ODATA V4): Read communication arrangements using this synchronous inbound service.

The above mentioned documentation regarding communication management is good start to dive deeper into the details on communication settings. Corresponding SAP Fiori apps are Maintain Communication Users (F1338), Communication Systems (F1762) and Communication Arrangements (F1763).

HTTP protection (csp, cors, framing) configuration

To protect the UI user, a status of the customer-defined Content Security Policy can be fetched as well as information on specific functionality available through protection allowlists, like clickjacking protection.

Content Security Policy - Read (Type: ODATA V4): Read Content Security Policy (CSP) using this synchronous inbound service.
Protection Allowlist - Read (Type: ODATA V4): Read the protection allowlists using this synchronous inbound service.

This section of the secure communication chapter of the SAP S/4HANA Cloud Public Edition documentation provides details on CSP and allowlists. Respective SAP Fiori apps are Manage Content Security Policy (F3856) and Maintain Protection Allowlists (F3195).

Trusted certificates

Retrieving a status of certificate trust lists for trusted certification authorities.

Certificate - Read (Type: ODATA V4): Read the client certificates and certificate trust lists using this synchronous inbound service.

Documentation covering certificate trust lists can be found here. The corresponding SAP Fiori apps are Maintain Certificate Trust List (F2275) for root certificates and Maintain Client Certificates (F5350) for client certificates.

Conclusion

With SAP S/4HANA Cloud Public Edition 2402, SAP enhances its security posture and enables customers to harness insights from the configuration status of various security features of SAP S/4HANA Cloud Public Edition.

ISAE 3000 for SAP S/4HANA Cloud Public Edition - Evaluation of the Authorization Role Concept

2024-04-24T18:37:57.586000+02:00

This blog post is featured in the SAP S/4HANA Cloud Public Edition Identity Access Management - Your Knowledge Base.

Introduction

Authorization plays an essential role when we are talking about the Identity Access Management strategy of any ERP solution. Authorizing is the function of specifying access rights/privileges to resources. Authorizations allow what you can do on the system, once you have been authenticated.

In the context of SAP S/4HANA Cloud Public Edition, SAP divides the business functionality into semantically meaningful business catalogs, representing tasks or subprocesses within a business process. These business catalogs are the most finely grained units regarding structuring of work and authorization assignment.

Background

Business catalogs grant access to an app, a set of apps, or individual aspects of an app. Some business catalogs have restrictions. These restrictions give customers the option to further specify the way the user might interact with the app: they may, for example, grant write or read access. Business catalogs are grouped into collections called business roles.

A business role generally contains multiple business catalogs and corresponds to a set of authorizations required to perform the tasks of a particular job description, for example, a warehouse clerk. On the business role level, restriction values of the contained business catalogs are defined. A business catalog might be contained in different business roles and might have different restriction values assigned in these different business roles.

But now the question comes up, how does SAP ensure that the business catalogs - as the smallest building block from an IAM perspective - are not containing any inherent segregation of duties (SoD) conflicts and are fulfilling proper development processes?

For this, SAP regularly hires an external auditor to perform assurance procedures as a reasonable assurance engagement in accordance with the International Standard on Assurance Engagements (ISAE) 3000 Revised, "Assurance Engagements Other Than Audits or Reviews of Historical Financial Information” (ISAE 3000).

In this blog post, we will see the scope of the ISAE 3000 Assurance Report as well as the steps for requesting a copy of it.

Scope of the ISAE3000 Assurance Report

The scope of this report includes assurance procedures on the design and implementation as well as the effectiveness of the SAP S/4HANA Cloud Public Edition Authorization Concept of SAP regarding development, design, and implementation to avoid SoD conflicts.

In order to gain reasonable assurance evidence, the external auditor decided to assess all relevant processes that influence the quality and usage of the released business catalogs by SAP to customers. Some of these assurance procedures refer to the technical backend view on the Business Catalogs, called Business Catalog Roles. Please note that the technical backend cannot be accessed by SAP customers.

The assurance procedures included the assessment of the business catalog role concept structure covered following aspects (technical view):

Business catalog roles implemented naming conventions
Development process for business catalogs
Rule-compliant definition of SAP S/4HANA Cloud Public Edition business catalog roles
SoD-compliant definition of SAP S/4HANA Cloud Public Edition business catalog roles

Additionally, the external auditor inspected the SAP-internal testing and change management process with regards to the business catalog roles. Ultimately, the business catalog implementation by SAP (as it is delivered to customers) has been evaluated. This part of the assurance involved walkthroughs with the involved development teams through the newly released SAP Fiori applications to SAP S/4HANA Cloud Public Edition.

Requesting a Copy of the ISAE3000 Assurance Report

The use of this report is restricted. A copy of this report is available for all SAP S/4HANA Cloud Edition customers with productive systems. This report is also available for prospective customers under the signed non-disclosure agreement. The report may include a qualified opinion.

For requesting the report, kindly follow these steps:

Go to SAP Trust Center
Select Compliance

Select Find Compliance Documents

Filter the List of compliance documents. Search in the Offering Name for SAP S/4HANA Public Cloud

Search and Click on Reasonable Assurance Report (ISAE3000) on the S/4HANA Cloud Edition Authorization Role Concept

Scroll down and click on the button Request a copy of the SAP S/4HANA ISAE 3000 Assurance Report

Conclusion

For more Identity Access Management-related topics on SAP S/4HANA Cloud Public Edition, you can check out my blog post SAP S/4HANA Cloud Public Edition Identity Access Management - Your Knowledge Base.

Please feel free to provide your feedback in the comment sections.

For more updates you can follow me via LinkedIn.

INFLUENCE THE DEVELOPMENT OF SAP ENTERPRISE THREAT DETECTION, CLOUD EDITION

2024-05-03T06:40:10.948000+02:00

Introducing influence page for SAP Enterprise Threat Detection, cloud edition.

The SAP Enterprise Threat Detection product team are inviting customers and partners to share their feedback and ideas to enhance our solution.

On SAP Enterprise Threat Detection, cloud edition Influence page you can see all submitted requests, submit your improvement requests, vote and comment on other ideas.

The rationale and advantages of a customer influence page include:

Augmenting customers engagement and influence on product features.
Improving product/services using meaningful customer insights.
Cultivating an engaged community.
Serving as a central platform for customer suggestions and fueling innovation.

The product team regularly evaluates the ideas and considers them for roadmap planning. Votes help to priorities ideas along with other important selection criteria such as:

DESIRABILITY: How many customers voted for this? How many customers will benefit from it?
VIABILITY: Is this Improvement Request globally relevant? Is this in alignment with SAP’s strategy for the product?
FEASIBILITY: Is the development effort realistic? Is this request achievable within the product’s architecture?

While this page is mainly for the public cloud edition, for private cloud and on-premise versions feel free to propose integration-related ideas.

Follow the steps below to get access and start sharing your enhancement ideas:

Go to SAP Enterprise Threat Detection, cloud edition Influence page.
- In case you are a new user, create a user account using S-User-ID and accept the Terms of Use. Once the user is created you activate SSO and can access without any interruption.

Follow the session to get notified of new Improvement Requests and blogs.
Vote and comment on Improvement Requests posted by other customers/ partners.
Submit new Improvement Requests.

You can also check out the videos\link below, if you wish to learn more about SAP Continuous Influence and how to submit and manage improvement requests:

Please reach us at SAP-ETD@sap.com in case of any issue.

We look forward to seeing your ideas and further improve our software as we move forward.

Threat Actors targeting SAP Applications

2024-05-03T07:57:35.500000+02:00

Last week, Onapsis and Flashpoint released a report describing the evolution of the Treat Landscape around SAP Applications, including the intersection of SAP and Ransomware. Some of its highlights include a 490% increase of the mentions to SAP exploits or vulnerabilities across the open deep and dark web from 2020 to 2023, or a whopping 400% increase in the price or an Remote Command Execution exploit for SAP Applications from August of 2020 to April of 2024.

These Threat Intelligence indicates that Threat Actors of all types understand how to target SAP technology, by exploiting SAP CVE(s), exfiltrating financial reports from SAP Applications, performing financial fraud over extended periods of time, or even through the execution of Ransomware, which also targets SAP Applications and data. Some examples of these Threat Actors are APT10, a state sponsored actor, FIN7/FIN13, which are financially motivated Threat Actors or Cobalt Spider, a cybercriminal group.

This is an effort moving in the direction of helping SAP Customers tackle cybersecurity threats such as active cyberattacks or ransomware, as done in the past jointly with SAP:

So as SAP Customers, what should we do?

In short, Vulnerability Management, Threat Detection and Threat Intelligence should integrate and incorporate SAP Applications.

Vulnerabilities and misconfigurations affecting SAP are used by Threat Actors to target SAP Applications, so SAP Customers should have proper vulnerability management programs addressing vulnerabilities and issues in a timely way. There are specific vulnerabilities and risks that were identified as part of this research so those individual CVE(s) and misconfigurations are among the ones we should prioritize. Having said that, SAP releases patches periodically (second Tuesday of every month) and we should be able to process them and react accordingly. As an example, these are the patches released by SAP on April 2024: SAP Security Patch Day – April 2024
Threat Intelligence tailored to SAP Applications should be consumed and integrated into Security Operation Centers, giving defenders the right signals to protect these applications before the bad guys act. Besides this recently released report, in the past, CISA has released a number of alerts, warning SAP customers about a number of different threats:
Feeds of logs and audit trails should be integrated into existing continuous monitoring programs to detect when SAP vulnerabilities are being exploited, SAP users are compromised or any other type of threat is affecting SAP Applications. These types of signals are extremely important to understand what happens through an SAP Application and to proactively detect potential threats.

If you are interested on reading more of this research, the report is available for download at both Onapsis and Flashpoint sites (SAP community policies do not allow to add the link directly on this blog).

Integration between SAP and One Identity

2024-05-03T08:31:39.439000+02:00

As SAP Identity Management (SAP IDM) reaches its end-of-maintenance, customers will need to explore alternatives for their identity management landscapes. Here are some key elements to consider:

Embracing industry standards

SAP Cloud Identity Servicesform the core of SAP’s IAM strategy, relying on industry standards such as Security Assertion Markup Language (SAML), OpenID Connect (OIDC), X.509 certificates and System for Cross-Domain Identity Management (SCIM). Any identity management solution considered should have strong support for these protocols and easily integrate with SAP Cloud Identity Services.

On-premises workload support

Given the diverse adoption levels and significant on-premises footprints among SAP IDM customers, strong support for on-premises workloads is a critical capability. Customers should also ensure that integration with SAP solutions are using supported and certified integration methods.

Migration expertise

Finally, customers should look for partners with experience in migration from SAP IDM to the partners solution, either through the partner’s professional services or through their network of partners.

Integration with One Identity Manager

SAP recently performed a proof-of-concept examining integration with solutions from SAP. The results:

One Identity was able to prove all use cases for both ABAP and SCIM based connectivity scenarios.
One Identity Manager has a long track record of support for ABAP workloads using a certified connector, support for Cloud Identity with SCIM, and a broad network of partners with experience both in SAP solutions and with One Identity deployments.
The One Identity Manager solution can manage the identity lifecycle of SAP users through the certified SAP Connector for ABAP based SAP systems. Due to the deep integration and the resulting SAP expertise, customers can be supported not only in managing their SAP accounts on different SAP systems, either directly or indirectly via a CUA, but also in license measurement. It can assign accounts, the necessary SAP licenses and thus support customers in licensing SAP users. The certified connector of One Identity Manager is also able to synchronize HR data from an SAP HCM system. Current developments are also constantly considered and adopted, so that the One Identity Manager in a modern S/4HANA instance is well aware of the business partner concept and fully supports them.

Integration with One Identity Manger and S/4

The following set of graphics will show an S/4 HANA system being connected to One Identity’s IGA solution.

First, an S/4 HANA system is selected:

Next, the clients to integrate are selected:

Within One Identity Manager, the SAP ABAP connector is selected:

Next, the data to integrate is selected. (note: although the button is labeled R/3, S/4 is supported):

One Identity Manager synchronizes client specific data as well as system specific information. The below screenshot shows the list of clients on this SAP S4/HANA system.

The One Identity Manager’s target system browser allows live browsing. The list of SAP users and their details are shown below.

The ABAP connector provides deep level attribute mapping, as well as the ability to map custom attributes.

Once the S/4 HANA system has been successfully connected with the appropriate Client(s), Users, and attributes mapped, the data model is synchronized into One Identity Manager.

A user’s SAP roles are synchronized.

Finally, changes made in One Identity Manager can be reflected back into S/4:

Customers who are already in a hybrid world and are utilizing RISE to migrate services to the cloud, have additional requirements for security, efficiency, and reliability. These customers not only have SAP's classic on-prem products and solutions in place, but also cloud-based solutions.

Hybrid SAP customers use services from the SAP cloud in addition to on-premises solutions. In this case, One Identity Manager can manage the ABAP-based SAP S/4HANA cloud private instances through the certified SAP connector, just like the on-prem ABAP-based SAP systems.

One Identity Manager can not only integrate SAP IAG, but also directly integrate applications on the SAP Business Technology Platform (SAP BTP). For this purpose, a SCIM-based standard connector is provided via their Starling Connect service, which enables integration via SAP Cloud Identity Services.

For customers utilizing SAP SuccessFactors, SAP Concur, SAP Ariba and other cloud hosted solutions, they can also be managed with One Identity Manager, ensuring holistic governance for our customers landscapes as they move forward.

Solutions like One Identity Manager will help facilitate a transition from SAP IDM to SAP Cloud solutions by supporting both ABAP and SCIM as well as other systems that customers have in their environments to help them satisfy their security requirements.

Shared Trouble is security doubled: the shared responsibility model for SAP S/4HANA Cloud

2024-05-07T09:21:45.077000+02:00

One of the advantages of cloud applications is that you don’t have to take care of security. Which is true – mostly. In reality, while most of the security responsibilities and tasks are taken over by the cloud service provider, there are some things which the customer still holds responsible for. And that also goes for the security responsibilities in SAP S/4HANA Cloud.

Now, the title of this article specifically mentions SAP S/4HANA Cloud, without specifying whether it refers to private or public cloud. This is intentional as the focus is on the customer's responsibilities in the S/4HANA Cloud responsibility model – and in the following I’d like to highlight the responsibilities of the customer in general, while detailing the differences between SAP S/4HANA Cloud Privat Edition versus SAP S/4HANA Cloud Public Edition.

Responsibilities in General

In terms of security, responsibilities are relatively clearly split between the Cloud Service Provider (CSP) and the customer. On a high level, the CSP’s responsibility includes security operations, network application, database management, operating system management, and the bare metal, unless partnering with a hyperscaler.

The customer, on the other hand, is responsible for the application's access and security. However, there's a significant distinction depending on whether we're discussing SAP S/4HANA public or private cloud.

Looking at it from another perspective, as the cloud service provider, we don't have access to your customer data, user identities, authentication, and business processes. The responsibility for these aspects lies with the customer. Conversely, security for the application server, database, operating systems, physical security, and bare metal security falls under our, SAP's, jurisdiction as a cloud service provider.

Understanding the difference is crucial, not just for security, but for adjacent topics as well.

Auditing cloud applications

In order to get an overview, let’s begin with how auditing is approached in different cloud deployment options. This will help elucidate why it's critical to clearly distinguish responsibilities between you as a customer and SAP as the cloud service provider.

When examining IT general controls, one should consider business processes, applications, and infrastructure. These elements require auditing by your auditor. IT application controls relate to business transactions and processes. The software, such as SAP S/4HANA, handles this. However, as the customer, you define the business processes and are therefore accountable to the auditor to ensure these processes function as designed.

Secondly, there are application-related controls. These involve access management, change management, security configuration, and monitoring of application jobs and integration scenarios. The goal here is to ensure the application is implemented securely and correctly to meet the requirements of the business processes.

The same principle applies to IT infrastructure, which must be implemented correctly to support business processes without negative impacts. This includes operating system and database security, but also physical data center security.

Customer Audits

When considering various cloud service models, the scope of the auditor's role varies significantly between on-premise installations and software as a service. In an on-premise model, the customer’s auditor must assess everything from physical security to business process controls.

Different Cloud Deployment Models

In an Infrastructure as a Service (IaaS) model, the auditor would need to rely on the cloud service provider for physical data center security and hardware matters. However, everything else, including service operating systems and databases, remains the customer's responsibility and must be audited accordingly.

With Platform as a Service (PaaS), like S/4HANA private cloud, responsibilities for the security of operating systems and databases shift to the cloud service provider.

Software as a Service (SaaS) extends this concept further, in cases like the SAP S/4HANA public cloud, where standardized software is used by all customers.

To manage these varying responsibilities, the SOC (Service Organization Control) report, specifically the SOC 2 report has been established as an industry standard. This report is an attestation from auditors that all controls regarding IT infrastructure and application responsibility are functioning as designed.

The SOC report's purpose is to prevent each customer's auditor from having to verify that a CSP is maintaining their controls correctly.

However, it's crucial to note that customers must request the SOC 2 report regularly from the CSP, review it, and ensure it aligns with their security requirements. Subsequently, the company and its IT auditors need to review the controls within the SOC 2 report to verify everything is in order.

The differences in SAP S/4HANA deployment models

Let's delve into the S/4HANA application, specifically focusing on the differences between private and public cloud options.

To do this, we could proceed alphabetically by topic, but the most effective approach would be through the lens of the SAP Secure Operations Map. This tool, although developed before the advent of cloud technology, remains relevant as it comprehensively covers all tasks required for running applications like S/4HANA.

SAP Secure Operations Map

As a brief overview, the map starts at the top with the organization, which isn't directly related to IT. It emphasizes the need for security governance awareness and risk management - an area that's often overlooked. In essence, it's crucial to identify potential risks, prepare responses, and manage them appropriately.

Next, the secure operations map addresses the application itself, highlighting aspects like access management, authentication, authorizations, and custom code security. It considers all customizations made in your SAP S/4HANA system.

On the system level, the map focuses on security hardening, secure SAP code, our secure development process, and security monitoring.

At the bottom of the map, mirroring the cloud responsibilities we've discussed, there’s the environment. This includes network security, operating system, database security, and client security.

Taking a closer look at this, and returning to the cloud deployment models we discussed earlier, we see that the Secure Operations Map's five topics (environment, system, application, process, and organization) are all the customer's responsibility in an on-premise environment.

In a private environment, the responsibility transitions between SAP and the customer around the application area. In a public environment, we, as the service provider, shoulder a larger share of the responsibility compared to the customer.

Network security is a shared responsibility between customers and SAP, regardless of whether the environment is private or public. As a customer, you must ensure that the network you use to access applications is secure. For instance, in a private environment, you may use SAP GUI via a VPN tunnel to our network. In contrast, in the public cloud, you can only access the software through a web browser over the internet. In both cases, you as the customer need to ensure that the network on your end is secured.

The operating system database security is our responsibility, again, regardless of whether it's a private or public cloud. Client security, on the other hand, such as ensuring the SAP GUI or web browser is set up securely, falls under the customer's domain in both cases.

When it comes to system security hardening, it's our responsibility, fully. Secure SAP code, from a development perspective, is our responsibility in both private and public cloud scenarios. However, there's a key difference when it comes to patch management in the private cloud. Here, updates are individual per customer and may affect business processes or require system restarts. Therefore, we coordinate with you before initiating any updates, unlike in the public cloud, where updates affect all customers.

Security monitoring and forensics represent another shared responsibility, but there are differences between Rise and Grow. In Rise, due to access to most of the ABAP stack, similar to an on-premise environment, you receive more information, including infrastructure logs provided by our private cloud operations team, a service called LogServe.

In a public cloud scenario, we provide a limited number of logs for security monitoring. Some information, technically, is shared among all customers; hence, we can't share it with individual customers.

The application

Let's delve into the application, specifically User and Identity Management.

When we discuss roles and authorizations, we see a distinction between private and public cloud environments. In a private cloud, customers retain access to the PFCG, the SAP system transaction where roles and authorizations are defined and implemented. It's important to note that while you do have PFCG access in the private cloud, it's not usually full access. You typically can't assign authorizations or access the roles and authorizations definition, PFCG, as an admin, particularly when it comes to technical security topics.

In the public cloud, we implement a different strategy. We use what we call business catalogues, the smallest units of roles and authorizations. These catalogues are combined to create roles within the application, aligning with your business processes.

Regarding Custom Code Security, your code is generally your responsibility. However, there's a slight difference between private and public clouds. In the private cloud, you have more opportunities to program additional applications on top of S/4HANA. In contrast, in the public cloud, we provide Developer Extensibility that allows business application extensions but limits access to low level functionality.

The last main topic from within the Secure Operations Map is Processes and Organizations. This is primarily the customer's responsibility, which is why we won’t discuss it here.

Conclusion: Lots and less to think about

As mentioned in the opening of this article: moving to the cloud gives you a lot less to think and worry about, especially when it comes to security. However, it does not relieve customers from all responsibility - something to keep in mind. On the other hand, we at SAP will support now and in the future by guiding customers through those settings they are responsible for. And by making S/4HANA Cloud the most secure ERP system.

Streamlining User Provisioning from IBM Verify to SAP Cloud Identity Services

2024-05-08T12:57:02.652000+02:00

SAP Cloud Identity Services (CIS), part of SAP BTP, can be used to integrate Identity Access Management (IAM). In our last blog, we discussed the integration of SAP Cloud Identity Services (CIS) with IBM Security Verify, and now we're taking the next step in this integration. User provisioning is the process of setting up new user accounts in a system or application. In this blog, we will explore a common use case - - transitioning user provisioning from IBM Verify to SAP Cloud Identity Services, and how this transition can streamline operations and enhance security.

The Challenge of User Provisioning

User provisioning is the process of granting and controlling access to resources within an organisation’s information technology infrastructure. Historically, on-boarding or off-boarding users has been a laborious and time-consuming procedure that frequently required numerous processes across multiple systems. As businesses embrace cloud solutions, the complexity of user provisioning has grown, necessitating automated and integrated approaches.

Transitioning from IBM Verify to SAP Cloud Identity Services

IBM Verify is a comprehensive identity and access management system that includes multi-factor authentication (MFA) and adaptive access control, while SAP Cloud Identity Services offers identity lifecycle management, single sign-on (SSO), and access governance features. Integrating these two systems can help organisations automate and streamline user provisioning operations, while also improving security and user experience.

How does it work?

The diagram shows that IBM Security Verify acts as a central user management system. It creates user accounts and manages their attributes, and also provisions them (or creates them) in SAP Cloud Identity Services, potentially syncing relevant user attributes. Selected attributes from Verify are mapped to specific target attributes in SAP Cloud Identity Services, ensuring consistent user information across both systems. SCIM, a standardised protocol, enables communication between Verify and SAP Cloud Identity Services. On the left side of the diagram, IBM Security Verify acts as a SCIM server, receiving requests for user management and then modifying the target directory as needed. This streamlines user creation and ensures consistent user information across both systems.

Prerequisites

SAP Cloud Identity Services (for trial instance check this link)
IBM Security Verify (for trial instance check this link)
A smartphone with IBM Security Verify App

Configurations and Settings in IBM Security Verify and SAP Cloud Identity Services

Log into IBM Security Verify as an administrator

When a user logs in, the home screen as shown below will be displayed.

On the left panel, click on "Applications" under "Applications". On the right side of the screen, there is an “Add application” button. Click on it.

Fill in the necessary details under “General” section as below and save the details.

Before we go further, let’s log into SAP BTP account and you will be navigated on SAP BTP Cockpit. As suggested below, navigate to the “Instances and Subscriptions” tab which is under “Services.”

You have to enable the cloud identity services application.

Once enabled, it will look as below. Now, click on Cloud Identity Services application and you will be redirected to the login screen of the SAP authentication screen as shown below.

After a successful login, you can see the home screen of Cloud identity Services. Go to the “Identity Providers” as highlighted below :

Click on the Corporate Identity providers and create new identity provider.

Once the new identity provider is successfully added, click on the identity provider type and select SAML 2.0 compliant, as shown below:

Go to the SAML configuration section and fill in the information as shown below:

You can browse the “Metadata” file from your device once you download it from IBM Security Verify dashboard. Go to the “Sign on” section of the application and on the right side of the screen, download the file from the given URL and upload the same in SAP Cloud Identity Services as highlighted below:

Click on the Trusting application section and add SAP BTP trial subaccount.

Establish the trust configuration, which is under the “Security” section for the cloud identity application as shown in the below screenshots.

You will see the below steps once you click on establish trust. In the first step, choose tenant and click on the next.

After selecting a tenant, choose domain for your SAP Cloud Identity Services application.

Click on the next button and configure parameters as shown in the below screenshot.

Click on the next button and review the setup that you have done while establishing the trust. Finally, click on the finish button and save the details.

Once done, you can see the trust new active trust configuration as shown below:

Now go back to IBM Security Verify and click on “Sign-on” section, then select “Use metadata” checkbox. It will allow us to upload the metadata file which we have downloaded from SAP BTP as shown below:

Upload the metadata file which you have recently saved on your device to IBM Verify dashboard.

Now go to the “Account lifecycle” tab and add SCIM URL, Username and password detail as shown in below image. You can get all the details from SAP Cloud Identity Services application page.

To get SCIM URL, go to SAP CIS and get the URL details from the browser and add “SCIM” at the end of URL.

After adding the above details, scroll down and you can see “Attribute mapping” section. Click on the checkbox for which attribute you want to map from IBM Verify to SAP CIS and want to keep updated. Here we have checked email. Save this detail once changes are completed.

We have completed the configurations in IBM Security Verify and SAP Cloud Identity Services. Let’s add user with attribute into Verify and check if it is mapped to Cloud Identity Users dashboard.

Go to the Users tab under the “Directory” section on the left side of the verify dashboard and click on the “Add User” button as shown in below screenshot.

Fill out the necessary information for the user as mentioned in the below image and click on the “Save” user tab.

Scroll down and you can add more detail about the user. Here we have added an email ID, mobile number and user company details.

Once done, click on the Save button and the user detail will be saved.

Open the Cloud Identity Services application and go to the user section to check whether the newly-created user from Verify is mapped.

Click on the “Instance and subscription” section from the “Services” section on the left menu, and once the application list is shown, click on the Cloud Identity Services application as shown below.

When the new application is loaded, click on the “User Management” tile and all the user list will be displayed.

As you can see in the below screenshot, a new user is created, which is added from Verify and mapped into SAP Cloud Identity Services. Also, the user detail is mapped into Cloud Identity Services.

Conclusion

Effective user provisioning is critical to maintaining security, compliance, and operational efficiency. Centralising identity management, improving security, and streamlining administration activities enables organisations to successfully manage user identities and access controls across their entire IT infrastructure. Embracing integrated identity management solutions is more than just convenient - - it is a strategic need for businesses looking to flourish in an increasingly linked and security-conscious environment.

More information:

Refer to our another blog on SAP Cloud Identity Service integration with IBM Security Verify.

If you have any question or query about SAP BTP please refer to SAP Community and for any question or query about IBM Security Verify refer to IBM Security Verify Community

SAP S/4HANA - Extracting User Email Addresses from Standard Tables

2024-05-10T15:09:30.362000+02:00

What are we discussing here?

When working with SAP systems, it is fundamental to need / verify user email addresses for various purposes. Whether it is to send Automated Notifications, facilitating communication between users, or Generating Reports, having accurate and up-to-date email addresses is crucial. However, extracting the email address from SAP system is not as easy as we think. In this blog post, we will explore the simplest method to extract / find email addresses of users from SAP Standard tables.

Note : There is no direct transaction code or program to extract email addresses of users

How are we going to achieve it?

The primary table that stores user information in SAP is USR21. This table contains User Master Data, including Personal Numbers (PERSNUMBER) associated with each user. To retrieve email addresses, we will link this table with the address data table ADR6.

What is USR21?

USR21 is a standard table in SAP ERP system that assigns User Names and Address Keys.

What is ADR6?

The ADR6 table in SAP ERP system is a standard table that stores email addresses (Business Address Services) for any address record.

Procedure to Extract Email Address from SAP Tables

Execute table view transaction code: SE16 -> Enter Table Name : USR21 -> Execute

Provide the list of User ID(s) through Multiple Selection for BNAME -> Execute

Copy the list of Personnel Number (PERSNUMBER) for the users

Execute table view transaction code: SE16 -> Enter Table Name: ADR6 -> Execute

Provide the list of Personnel Number(s) through Multiple Selection for PERSNUMBER -> Execute

SMTP_ADDR column of ADR6 table will provide the list of email address for users

SAP also offers to extract the list into Spreadsheet from this screen

Tip : Ensure to select ALV Grid Display in User Specific Settings at initial screen of ADR6

Word of Caution

Avoid Unintended Disclosure

When querying SAP tables, be cautious not to inadvertently disclose email addresses to unauthorized users or external sources.

Limit access to relevant personnel and follow proper authorization procedures.

Remember, accurate and secure email addresses contribute to smooth business processes and effective communication within your organization. Handle them responsibly, and always prioritize data protection.

If you have any further questions or need assistance, do not hesitate to comment on this blog. Happy SAP querying!

Feel free to share this article with your colleagues and peers who work with SAP systems.

SAP Community - Security

SAP Cloud Integration: Understanding the XML Encryption Standard

Overview

History

Introduction

Sample XML

Optional Info

Summary

Next Steps

Links

Oil & Gas - Ultimate Data Security - Blockchain Data Backbone from OT to SAP IT🚀

A Robust Security Package for the SAP Customer Data Cloud (CIAM)

The What Is... The Why To... The How To... of: ESG & SAP & Enterprise Blockchain 🚀

SAP Mobile Start V1.11 - Release Update

SAP IdM migration guidelines to help you on your upcoming IAM journey

Security in SAP Analytics Cloud, free learning journey

SAP Integration Suite – Access Policies for Integration Packages

Use Cases

Compatibility with Access Policies for Specific Artifact Types

SAP Enterprise Support Highlights Resources to Achieve a Clean Core

“Clean core. . . to sum it up is the one key puzzle piece . . . to be an agile intelligent enterprise.” - Markus Albrecht, Adoption Services Center General Manager for SAP BTP

Clean Core Explained

SAP Enterprise Support Value Maps Can Help Get You There

With you in mind, value maps provide structured self-paced learnings to advance your digital skills; access to collaborative forums and SAP experts for personalized guidance; and continuous quality checks to mitigate implementation risks or identify optimization potential.

Where to Access

References

Further Information

Beyond Basic (1): Certificate-Based Authentication

Why Certificate-Based Authentication?

What is a Client Certificate?

And What is a Signature?

How Does That Authenticate a Client?

Client Certificate, Server Certificate – What's the Difference?

How do the Two Come Together?

Aside: Root Keys, PKIs, Validity

Root Keys and the Chain of Trust

Public Key Infrastructure

Local PKIs/CAs

Certificate Validity and Rotation

Up Next: How to Actually Use Client Certificates in SAP S/4HANA Cloud Public Edition

Beyond Basic (2): Certificate-Based Authentication in SAP S/4HANA Cloud Public Edition

Step One: Get a Client Certificate

Create the Private Key and Signing Request

Get the Certificate Signed by the CA

Convert PKCS#7 Certificate to .pem Format if Needed

Step Two: Create a Communication User and Upload the Certificate

Step Three: Reference the Communication User in a Communication System

Step Four: Reference Communication System and -User in a Communication Arrangement

Sep Five: Try it Out

Call Using Bruno

Call Using cURL

Do we Trust the Server? How to Get the CA Certificate?

What we Achieved

SAP Secure Login Service for SAP GUI Now Supports Custom Certificate Authorities on AWS

SAP S/4HANA Cloud Public Edition: Security Configuration APIs

Available Use Cases and APIs for SAP S/4HANA Cloud Public Edition

Business user role/authorization configuration

Detection of unused users/connections

Communication settings (authentication methods etc.)

HTTP protection (csp, cors, framing) configuration

Trusted certificates

Conclusion

ISAE 3000 for SAP S/4HANA Cloud Public Edition - Evaluation of the Authorization Role Concept

Introduction

Background

Scope of the ISAE3000 Assurance Report

Requesting a Copy of the ISAE3000 Assurance Report

Conclusion

INFLUENCE THE DEVELOPMENT OF SAP ENTERPRISE THREAT DETECTION, CLOUD EDITION

Threat Actors targeting SAP Applications

Integration between SAP and One Identity

Embracing industry standards

On-premises workload support

Migration expertise

Integration with One Identity Manager

Integration with One Identity Manger and S/4

Shared Trouble is security doubled: the shared responsibility model for SAP S/4HANA Cloud

Responsibilities in General

Auditing cloud applications

Customer Audits

“Clean core. . . to sum it up is the one key puzzle piece . . . to be an agile intelligent enterprise.”

- Markus Albrecht, Adoption Services Center General Manager for SAP BTP