SAP Community - SAP BTP Security

Custom domains for BTP CloudFoundry applications

2024-03-26T08:43:26.536000+01:00

Introduction

I wanted to activate a custom domain on BTP for my own website https://wouter.lemaire.tech . To achieve this I followed this great step-by-step blog post of @andrew_lunde : https://community.sap.com/t5/technology-blogs-by-sap/step-by-step-guide-to-custom-domains-with-multitenant-multi-target/ba-p/13390754

Nevertheless, I did some steps different which still made it challenging to configure:

I bought the domain using google domains
Used certbot instead of my own certificate (in companies you’ll probably have a company certificate)
Added MTA configuration to automatically map the domain after deploying your app

Those differences changed some steps in the flow which I documented and want to share in this blog post.

Prerequisites

Check the official SAP help documentation, this might help you to understand the flow: https://help.sap.com/docs/custom-domain/custom-domain-service/create-custom-domains?locale=en-US

You need to buy a custom domain, this is not part of this service. This service just allows you to use your custom domain (which you pay separately) to your BTP applications and services. I’m using google domains which has been migrated to Squarespace.

Install certbot: https://certbot.eff.org/instructions?ws=other&os=windows

Download the latest version of the Certbot installer for Windows at https://github.com/certbot/certbot/releases/latest/download/certbot-beta-installer-win_amd64_signed.exe.

Make sure your BTP account has the entitlements:

Create an instance of this service in your CloudFoundry Space:

Install the CloudFoundry CLI with the Custom Domain Self-Service plugin. The plugin can be downloaded from here: https://tools.hana.ondemand.com/#cloud

Once downloaded, install it by going into the folder of the plugin and run the following command in your cli: “cf install-plugin custom-domain-cli”

Validate if it was successful by running “cf plugins”. This will show you a list of all installed plugins including the custom domain plugin:

Create your custom domain

1) Login to CloudFoundry using the cli:

2) Create your custom domain using the command “cf create-domain wlcf wouter.lemaire.tech”

You can validate if this was successful with the command “cf domains”, here you should see your domain listed:

3) Create a private key for your custom domain in Cloud Foundry using the command:

cf custom-domain-create-key custom-domain-wouter-lemtech-key "CN=*.wouter.lemaire.tech, EMAIL=wouter@lemaire.tech, O=lemtech, C=BE" "wouter.lemaire.tech"

custom-domain-create-key: command for the cf cli custom domain plugin to create the key
custom-domain-wouter-lemtech-key: this is the name for the key that will be created. We need this in a later phase
“CN=*.wouter.lemaire.tech, EMAIL=wouter@lemaire.tech, O=lemtech, C=BE” : details need to create the CSR
"wouter.lemaire.tech": the domain name I want to connect (more can be listed here)

4) Get the Certificate Signing Request (CSR) by using the created private key using the following command:

cf custom-domain-get-csr custom-domain-wouter-lemtech-key csr.pem

custom-domain-get-csr: cf cli custom domain command to retrieve the csr
custom-domain-wouter-lemtech-key: name of the private key which was created in the previous step
csr.pem: name of that will be used to store the csr in

5) Sign the CSR using certbot by running cmd as administrator from the folder where the csr.pem file is stored and run the following command:

certbot certonly --manual --csr ./csr.pem --preferred-challenges dns

This will give you a token which you need to use to create a TXT record in Google Domains:

Once you created the record, you can press enter. This might take a while but eventually provide you some certificates:

6) Upload the signed certificate to CloudFoundry

As I received three certificates from certbot and it was not clear which one to take so I tried merging all of them into one:

When uploading the combined certificate using the following command, it went in error:

cf custom-domain-upload-certificate-chain custom-domain-wouter-lemtech-key allchain.pem

So I tried all certificates separately and eventually the last one worked 😊

cf custom-domain-upload-certificate-chain custom-domain-wouter-lemtech-key 0001_chain.pem

custom-domain-upload-certificate-chain: command to upload the certificate to CloudFoundry
custom-domain-wouter-lemtech-key : key that I created earlier
0001_chain.pem: certificate that needs to be uploaded

It will ask for confirmation and upload BUT not yet activate:

We can check if the certificate was uploaded successfully with the following command + the private key:

cf custom-domain-show-certificates custom-domain-wouter-lemtech-key

7) Activate the custom domain using the following command:

cf custom-domain-activate custom-domain-wouter-lemtech-key wouter.lemaire.tech

custom-domain-activate: command for activating
custom-domain-wouter-lemtech-key: private key name
wouter.lemaire.tech: domain to be activated

You can check if the active custom domains in CloudFoundry with the command: cf custom-domain-list

In my case, I have two, one main custom domain which I’ll use to continue “Wouter.lemaire.tech” but also a generic domain that allows me to use subdomains “*.wouter.lemaire.tech”. I’ll use this one later.

8 ) Configure DNS for custom domain

Before we can do this, we need to get the API of CloudFoundry in your subaccount. This can be done by using the command “cf api”:

In Google Domains, I created the following record:

To test if it works I used the command “nslookup Wouter.lemaire.tech”:

9) Map application to custom domain

Before we do, we can check the list of apps to find the connected route for each application

With the following command, we will map an app with the custom domain we created (this needs to be done for the approuter app as this is the access point for an application in BTP):

cf map-route <Application Name> <Custom Domain> --hostname <Application Hostname>

In my example it looks like this, without the hostname as I want it to be connected with the main domain:

cf map-route lemtech-approuter wouter.lemaire.tech

If you now check the list of apps, you’ll see that the route for the approuter is connected to the custom domain:

You can also check the list of routes:

10) Configure the MTA of your app

After every deploy the mapping between the route and your app will be gone and you need to do this over again. This can be done in the BTP Cockpit:

You can avoid this by configuring the domain in the mta.yaml file of your application as followed:

With this configuration you’ll keep the domain connected to your application after each deploy

That’s how it’s done 😊

Result

Try navigating to https://wouter.lemaire.tech this will open my website which is running on SAP BTP Cloud Foundry!

Additional

Additionally I’m also want to create subdomains so I can use the custom domain for other applications. For this, I added a record in google domains as followed:

I have activated the custom domain “*.wouter.lemaire.tech”

Mapped the application BTP Service Overview with the custom domain Wouter.lemaire.tech using btp-services as hostname:

Result: https://btp-services.wouter.lemaire.tech/

Integrating IBM Security Verify with SAP Cloud Identity Services in SAP BTP

2024-04-02T10:29:43.856000+02:00

This blog delves into the technical aspects of integrating IBM Security Verify with SAP Cloud Identity Services (CIS) in SAP Business Technology Platform (BTP) as a proxy.

SAP CIS offers a suite of solutions for managing user identities, access controls, and application integrations across the IT landscape. Conversely, IBM Security Verify provides identity governance, workforce and Customer Identity Access Management (CIAM), and privileged account controls through automated, cloud-based, and on-premises capabilities. By integrating these platforms, organisations can leverage their combined strengths to establish a secure business environment. This integration enhances operational control, regulatory compliance, and user experience in the digital era.

IBM Security Verify supports various authentication methods, including passwordless, fingerprints, and one-time passcodes, ensuring flexibility and robustness against unauthorised access. Meanwhile, SAP Cloud Identity Services serves as a comprehensive Identity and Access Management solution which is available in SAP BTP.

The integration process involves configuration updates in SAP CIS and IBM Security Verify to enable authentication utilising standard protocols supported by both components, such as SAML 2.0. Organisations must ensure they have the necessary admin privileges or access rights for editing configurations before initiating the integration procedure. Collaboration between the organisation and SAP is required for the integration, with most of the effort undertaken by the organisation.

Reference Architecture

The diagram represents a SAP Cloud Identity Service that integrates with IBM Security Verify though which various SAP BTP application(s), SAP SaaS solution(s) and on-premises application(s) can be accessed. It demonstrates user sign-in via IBM Security Verify which allow possible passwordless, bio-metric or multi-factor authentication (MFA) using mobile devices for fast application access and pleasing user-experience.

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

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

Now 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 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”.

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

Configurations and Settings in SAP Cloud Identity Services

Now, get back to SAP BTP and navigate to “Instances and Subscriptions.”

Now, enable the “Cloud Identity Services” if it’s not and once done it will be accessible as below:

Once you click on “Cloud Identity Services”, you will be redirected to the login screen of the SAP authentication screen as shown below

After successful login, you can see the home screen of Cloud identity service. 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 added successfully, 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 “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 Service as highlighted below:

Click on the Trusting application section and add SAP BTP trial sub-account.

Now, navigate back to SAP BTP cockpit and establish the trust configuration which is under “Security” section for the cloud identity application as shown in the below screenshots.

Select “Establish Trust”

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

After selecting a tenant in the next step choose the domain for your SAP Cloud identity services application.

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

Click on the next button and make a final review of the setup you have done while establishing the trust. Then click on the finish button and save the details.

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

To provide access to the user, click on the Users section which is inside the “Security” section on the left menu.

Click on the user and assign role collection to the user as shown below.

You can select different roles and assign them to the user. Here we have added three roles to the user. After selecting all the roles, click on the “Assign role collection” button and save the details.

We have completed the configurations in IBM Security Verify and SAP Cloud Identity Services. Let’s test it now by opening the SAP business studio application as shown below.

How does it work? Let’s Check.

Log into SAP BTP Cockpit and Navigate to “Instances and Subscriptions” under “Services” as highlighted below:

It will redirect to the sign in options screen of the SAP. Here, select SAP cloud identity service as an identity provider.

Once you select, it will redirect to the verify sign in option screen for a authentication. Here you can select a different sign in option for Verify or can log in with IBM id/Cloud directory.

Enter your IBMid for log in and click the continue button.

It will redirect you for w3 authentication screen where you can enter your w3 id & password.

Once you click on sign in, you will see below screen of SAP business application studio.

Click on the “OK” button and you will be redirected to the SAP Business Application Studio home screen.

Conclusion

To summarise, combining IBM Security Verify with SAP Cloud Identity Services via SAML 2.0 provides a strong solution for organisations wishing to:

Enhance security: By implementing multi-factor authentication and centralised user management, businesses may greatly minimise the risk of unauthorised access to vital data and applications.

Improve the user experience: SAML 2.0 integration offers single sign-on, which allows users to access various applications with a single login, eliminating login fatigue and increasing overall user experience.

Simplify identity management: Consolidating identity management across several platforms allows organisations to streamline administration operations and reduce the complexity of managing user access.

Overall, this integration enables organisations to achieve a balance between strong security and a user-friendly interface, building trust and confidence in this digital era.

Single Sign On to SAP Cloud Integration (CPI runtime) from an external Identity Provider

2024-04-11T06:53:39.270000+02:00

Introduction:

Yes, you read it right (and you read it right here !). There is an out-of-the-box approach to achieving a single sign-on (SSO) experience for user flows between a corporate identity provider (that authenticates and authorizes the user) and a tenant of Cloud Integration runtime (loosely called CPI worker) fully within the BTP ecosystem.

Ok, let’s zoom out a bit and break this down.

If you are reading this blog post, you probably know already that SAP BTP Services can leverage the OpenID Connect federation-based mechanics of SAP Cloud Identity Service (read: SAP IAS) to connect users from corporate Identity Providers like Entra ID (formerly known as Azure AD), Okta, etc. to XSUAA BTP’s OAuth Authorization Server.
This is certainly not uncharted and I did a detailed blog post a few months ago demonstrating this setup.

However, this setup applied mostly to browser-based SaaS applications (read: Design Time applications with a web frontend), and that brings us to the objective of this blog -> Customers want to put together a similar setup for their client applications that interface with SAP Cloud Integration’s IFLows (in other words, the CPI runtime).
Certainly, this is not impossible to achieve and solution blueprints like these have existed in the past:

My colleague Francisco’s blog puts API Management in between a client and Cloud Integration and enforces API Management to perform an OAuthSAMLBearer handshake.
Microsoft champion Martin Raepple teaches how to set up SAML Trust between Entra ID Identity Provider and BTP to set up a user impersonation flow.

However, these approaches were often seen as cumbersome to set up / troubleshoot and certainly not for the faint-hearted!

Solution Summary:

An easier solution can be described in two phrases: 'OpenID Connect' and 'Authorization Code grant type'. If you are super-smart then you've figured it out already. You can stop reading this blog and hack this yourself.
I wish you a nice day ahead! If you are like me and need a bit more explanation, keep reading 🙂

Here is the solution blueprint that explains that handshake:

SCENARIO: Flows that require end-user authentication from external Identity Providers can natively do so with OIDC and Authorization Code grant type

Step 0: Generate Service Instance / Service Key SAP Cloud Integration Runtime. Refer to this link. Instead of Client Credentials make sure to select Authorization Code.

Step 1: Onboard the needed corporate identity providers in SAP IAS and set up the 'Application' that connects back to your SAP BTP Subaccount as a Trusted Identity Provider via OpenID Connect. Refer to my previous blog post for a detailed procedure.

Step 2: Client (end-user) initiates a connection to the required IFlow (or API artifact). This kicks off the 3-legged OAuth user login flow.

Step 3: As the user is not signed in, she is redirected to XSUAA's login endpoint, and upon login the IAS tenant's OAuth server authorization endpoint at https://<IAS tenant name>.accounts.ondemand.com/oauth2/authorize is invoked using the authorization code grant type. The details of the actual federation as part of the handshake have been omitted here for simplicity. But suffice it to say that the authorization code from the identity provider is made available to the IAS's callback endpoint and finally made available to XSUAA's authorize endpoint and exchanged for the actual access token. This access token will bear the user's scopes and role permissions needed to access the Cloud Integration's IFlow resource.

Step 4: Once successfully authorized, on the receiver side of the IFlow, we will establish connections to 3 different types of backends for illustration purposes. a) S/4HANA Onpremise system over Cloud Connector and Principal Propagation b) SuccessFactors and c) S/4HANA Cloud with OAuth2 SAMLBearer Assertion security material.

Putting it all together:

Let's get our hands dirty by putting together the sequence now. The prerequisites to follow along are listed below:

Administrator privileges in the BTP subaccount where the Integration Suite subscription exists.
An IAS Tenant (with Administrator privileges) that can be coupled (read: Trusted) with the said BTP Subaccount.
Privileges to create Applications (read: IDP configurations) in Entra ID (Azure AD) and/or Okta.
Postman Client.
Backend systems to which the frontend user principal can be propagated to. Either of S/4HANA OnPrem, S/4HANA Cloud, or SuccessFactors tenant.

Step 0: Create a Service Instance for the Authorization Code grant type

Create an instance of the 'Process Integration Runtime' Service (integration-flow service plan) specifically with the authorization code grant type. You can copy the JSON snippet pasted below. Do not worry about the location of the redirect_uri. (When we get down to testing the flow, the browser will invoke the redirect_uri, but this has no consequence as the 'code' will be available for us to copy as a query parameter from the URL itself. When we test this from Postman the client, Postman does not invoke the URL. If you are curious to know, you can read about it here.) Also, make a note that we have specified refresh_token as part of the requested grant type. This will let us demonstrate the ability for clients to refresh the access token post-expiry.

{
    "grant-types": [
        "refresh_token",
        "authorization_code"
    ],
    "redirect-uris": [
        "http://localhost"
    ],
    "roles": [
        "ESBMessaging.send"
    ]
}

With the service instance created, generate a service key (example block is pasted below). Grab the clientid, clientsecret, authorizationurl, tokenurl attributes. We will need these later.

Step 1: Configure OpenID Connect based Trusted Identity Provider of SAP IAS in your SAP BTP subaccount

This step is the heart-and-soul of our approach. We will couple an SAP IAS tenant with our BTP subaccount that has the subscription of our SAP Cloud Integration (SAP Integration Suite) tenant using OpenID Connect protocol and then onboard the desired external Identity Providers (I will demonstrate Entra ID and Okta) as corporate identity providers in the IAS administration console.
Since I've documented the steps in my previous blog, I will not repeat the exact steps here. Please refer to the following sections in the linked blog.

Objective	Steps to follow from the linked blog
Couple your BTP subaccount and your SAP IAS tenant.	Steps 1-6
Configure applications (relying party) in Azure AD and Okta IDP based on OpenID Connect and SAP IAS as the callback URI.	Steps 7 - 25
Configure application in Okta with SAML Trust to SAP IAS.	Steps 26 - 33
Onboard the above Corporate Identity Provider configurations into SAP IAS.	Steps 34 - 46
configure IAS as the proxy Identity Provider and SAP BTP as the Service Provider.	Steps 47 - 52

Nevertheless, here is a summary of the main steps involved in the setup.

1. The subaccount where the Integration Suite subscription exists has a 'Trusted connection' with the OpenID Connect protocol (not SAML) to the IAS tenant.

2. The IAS tenant has a 'Corporate Identity provider' connection to Azure AD (Entra ID) via a set of Application credentials and OpenID Connect protocol.

3. Notice the 'Application' settings on the Azure side. The redirect URI has been set to the IAS tenant's '../oath2/callback' segment

4. The IAS tenant has a 'Corporate Identity provider' connection to Okta IDP via a set of Application credentials and OpenID Connect protocol.

5. Notice the 'Application' settings on the Okta side. The redirect URI has been set to the IAS tenant's '../oath2/callback' segment.

6. We will not leverage this flow in our demonstration but note that it is very much possible to use SAML bindings between the Corporate Identity Provider and IAS. The federation works exactly as OIDC.

7. Next, we want to demonstrate a dynamic / Group assertion / Role Collection based user role/authorization determination. For that note that on the Azure side, we have a group called 'IntegrationDevelopers' that contains the users who must be authorized to call the IFlow / API on the Cloud Integration side.

8. Notice how the 'groups' claim on the IAS side resolves to the value of the group from Azure.

9. Similarly, see that the target user has been assigned to the 'IntegrationSuiteDevelopers' Group in Okta.

10. Okta presents the user's 'Groups' claim to IAS that XSUAA will resolve in a later step.

11. As a last configuration step, notice that there is a RoleCollection on the BTP side (with the 'MessagingSend' role assigned) mapped to the respective groups from the source identity providers.

Step 2 & 3: Initiate the client flow.

The easiest way to demonstrate a client flow is to do so in Postman which natively supports simulating an OAuth 2.0 3-legged Authorization Code grant flow. We can break down the segments of the 3-legged flow in a browser as well. I will demonstrate both of these user agents.

Summary of the steps about to be performed in this section

Objective	Steps
Use Postman to set up Authorization Code flow with Okta Identity Provider	1-8
Use Postman to set up Authorization Code flow with Entra ID Identity Provider	9
Usage of Refresh Tokens	13-14
Use Browser to set up Authorization code flow with Identity Providers	15-18

1. Within the 'Authorization' tab in Postman, set the 'Type' to 'OAuth 2.0' and the 'Grant type' to 'Authorization Code'.

2. Enter the values for the Callback URL, Auth URL, Access Token URL, Client ID, Client Secret from the values saved in the Step 0 block above.

3. Click on 'Get New Access Token'. Make sure to turn on the 'Console' tab at the bottom to keep track of requests and responses across the wire.

4. Postman will launch the Logon pop-up from BTP's Authorization Server. Notice that you are presented with a list of Identity Providers to log into as configured in BTP's Trust Management section. Select the one that corresponds to your IAS Tenant.
Pay attention to the GET requests in the Console tab. You will see that the request to the 'authorize' resource is being redirected to the login page.

5. The system will prompt you to present the user identifier, this will serve as an input to the 'Conditional Authentication' block set in the IAS tenant to resolve which corporate identity provider to redirect to, for the user logon challenge.

6. The system determines that the challenge should come from Okta IDP for my *.sap.com user name. Please refer to the 'Conditional Authentication' screenshot to get a summary of the determination process.
In the 'Console' section, make a note of how the callbacks are handled.

Conditional Authentication section in SAP IAS

7. Okta will authenticate the user and present back the 'authorization code' to IAS.

8. Finally the client will exchange the authorization code for the access token from the configured token endpoint.

9. Let us now perform steps nos. 3-8 again, but this time let us log in with our *.outlook.com user that gets authenticated and authorized from Entra ID (Azure AD).

10. Upon inspection, you will note that the access token issued by XSUAA has the 'ESBMessaging.send' scope as determined by the 'Groups' claim presented by the source IDP. You will remember that we created a mapping for this resolution in a previous step. Also, note that the system bears a refresh_token.

11. Further, if you inspect the respective JWTs issued by Okta and Entra ID, you will see that the tokens contain the claims that represent the Groups, RoleCollections, and User Identifier info.

12. Simply go ahead and 'Use Token' to load the token to make your request.

13. Using the refresh_token -> Notice that the token will expire after a set duration (based on the 'expiry' setting). As you can see in the screenshot below, Postman detects that the available token is expired. It gives an option to 'Refresh' the token. Click on this button.

14. Make a note in the Console tab that the client POSTs to the token endpoint with the available refresh_token and the refresh_token grant_type to get a fresh access token.

15. In the next screenshots, let us perform the same set of steps in a browser. We will need to frame the URL to the /oauth/authorize endpoint. The easiest way to do so would be to copy the URL from the Postman Console we referred to before. The URL is in the format :

https://<tenant-id>>/authentiation.<dc>.hana.ondemand.com/oauth/authorize?
response_type=code&client_id=<url-encoded-client-id>&redirect_uri=<url-encoded_redirect_uri>

16. Invoke the URL in a browser.

17. After the 'login' and 'authenticate' procedures, you will see that the browser is redirected to the redirect_uri location. You can copy the 'code' parameter from the URL.

18. Go back to Postman and POST the Access Token endpoint with the grant_type set to authorization_code and the copied code and the redirect_uri. The server will respond with the access_token with the same set of attributes populated as demonstrated in Step 11.

Step 4: Integration Flow Reciever side propagation

Now that we have an access_token that can be presented to the Cloud Integration runtime (to a 'Sender Adapter'), let us put together a simple IFlow that can demonstrate the fact that the user's identity from the external identity provider can be propagated to 3 backend systems - a) S/4HANA Onpremse, b) SuccessFactors and c) S/4HANA Cloud via Principal Propagation and OAuth2SAMLBearer mechanisms respectively.

Here is a summary of the steps we intend to achieve:

Objective	Steps
Create a sample IFlow that demonstrates the user propagation sequence to 3 different types of backend systems.	1-2
Invoke S4HANA Cloud backend	3 - 7
Invoke SAP SuccessFactors backend	8 - 13
Invoke SAP S/4HANA Onpremise backend	14 - 17

1. Let's start by putting together a simple IFlow to illustrate the user propagation flow. Since we are planning to invoke with 3 backends, the quickest way to demonstrate this would be to create a Router that has 3 branches. Each with a 'Request-Reply' step for the backend type, S/4HANA Cloud, SuccessFactors, and S/4HANA OnPremise respectively.

2. The logic we will follow is that the client passes a value in a custom header named 'target' that shall determine which of the routes is to be invoked.

3. In the property sheet of the HTTP Receiver for S/4HANA Cloud backend, notice that we've used a credential named 's4hanaCloudCredentials' with the OAuth2 SAML Bearer Assertion type.

4. I will not get into the details behind how the attributes of this Security Material have been formulated. Refer to parts of this blog post for details. The points worth mentioning here are that a) we are using the target system type SAP BTP (CF) and b) the 'userIdSource' attribute is annotated for 'email' & nameIdFormat is set to 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress', thereby implying that the user identifier from our original JWT token negotiated with the corporate identity provider will serve as the user principal to be propagated.

5. Let us make a call to the IFlow URL with the access token set from step 8 described in the above section. Note that we've set the 'target' header attribute to 's4hanacloud' so that the call gets executed in the first route. We get an HTTP 200 OK and the service document as the response and there you have it! We were able to successfully propagate the user from an external identity provider and execute a call in an S/4HANA backend with the user's context.

6. How do I prove my point that the user was indeed propagated? The next two screenshots do so. Note that on the S/4HANA side, I have a 'Business User' that bears my (that is propagated from Okta) emailID. Also, note that the HTTP Call is executed with this user context and NOT with a Communication User (technical user) attached to the Communication Arrangement.

7. Further to prove my point, I execute step no. 5, this time by presenting my *@outlook.com user (that comes from Entra ID), you see that the call fails and the error description calls out that the backend was not able to resolve the presented *.outlook.com user.

8. Let us now look at the 2nd route, the one that invokes a SuccessFactors URL. We extend the same 'OAuthSAMLBearer Assertion' type with a credential named 'SFSFUserPrincipal'. On the processing tab, you will see that I'm invoking a GET Query on the JobProfile resource.

9. In the details of the Security Material, note that we've set the attributes per SuccessFactors documentation. The User ID is set for principal propagation. Like before, we've used the same nameIdFormat as set in step 4 above, and don't forget to include the apiKey attribute as well.

10. Let us now invoke the IFlow, this time around with the header 'target' set to 'sfsf'. I get back a response from SuccessFactors with the JobProfile details.

11. Again, how do we prove that the call indeed was made in the signed-in user's context? There are many ways to establish this. A simple way I followed was to put a 'proxy' layer like API Management before the call hits the SuccessFactors backend and print out the 'Bearer token' from the 'Authorization' header. Upon Base64 decoding the token, you will see that the token bears a 'sfPrinciple' attribute with the employee ID identifier.

12. Look up the employee profile of the user in question in your SuccessFactors tenant and you can verify the matching employee ID and the corresponding email address.

13. Negative testing -> If I perform the call again, this time by signing in with the email address from Entra ID you should see a 401 unauthorized exception stating that the propagated user wasn't resolved.

14. Finally, we are down to the last segment of our testing. A connection to S/4HANA On-premise. I've configured an SAP Cloud Connector and an X.509 certificate signing procedure (that is beyond the scope of this demonstration) and have dialed 'Principal Propagation' for the authentication type.

15. Invoking the client this time around with the 'target' header set to 's4hanaonpremise'. I get back a response from the server with my service document for the invoked GWSAMPLE_BASIC OData service.

16. As a quick verification step, let us go to the 'Monitor' section in the Cloud Connector and within the 'Most Recent Requests' tab, you can see a record for the 'User' that was propagated.

17. Open the LJSTrace log file and you can hunt down a log entry that corresponds to the user subject that was propagated via the short-lived x.509 certificate.

Phew!

Summary:

It is beyond doubt that 'client credentials' and 'x.509 certificate' are the two most prominent and widely popular ways to authenticate to an Integration Flow / API artifact in SAP Integration Suite, but should you have a requirement to authenticate and authorize with the client user's identity from a corporate Identity Provider, OpenID Connect support from SAP Cloud Identity Service along with the Authorization Code grant type in SAP Integration Suite provide an excellent and out-of-box approach to get your job done.

Cheers, and more power to the SAP Integration Suite Community!

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

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.

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

What are other options?

Another approach for SAP S/4HANA is to leverage the built-in Core Data Services (CDS) view.

Table : PUSER002 can also be used | BNAME = UserName | Ensure column SMTP_ADDR is visible

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.

Identity Access Management (IAM) Reference Architectures 2024

2024-05-10T17:20:21.397000+02:00

Identity Access Management Reference Architectures in 2024

We are happy to share with you that we just released an update to our reference architectures (2024 version).

The latest version is published in SAP Discovery Center along with further links to our documentation and to related missions. We want to support you trying out easily what we describe.

If you are new to this topic, consider reading my older blog post about Cloud leading Identity Lifecycle from 2021. The 1st chapter is still valid to start with - although it's 3 years old 🙂

We have an updated version of the SAP Secure Operations Map which allows you to verify your security requirements and map them to the regional requirements like NIST or BSI.
The Secure Operations Map contains in the application layer the three main IAM pillars that are now described in the SAP Discovery Center:

Authentication flows

Authorization flows as part of the identity lifecycle

Identity Lifecycle flows

Please read them and we can use this community to discuss.

If you want to know more about the SAP Cloud Identity Services I recommend this blog post.

PS: Yes, we are already working on an integrated architecture which considers SAP Access Control - but we need a bit more time.

Installing SAPRouter on Linux: A Step-by-Step Guide

2024-05-11T15:55:48.753000+02:00

What is SAP Router ?

SAPRouter is a software component used to secure communication between SAP systems and the internet. Installing SAPRouter on Linux is a crucial step in ensuring secure communication for your SAP landscape. This step-by-step guide will walk you through the installation process.

Prerequisites:

- Linux server (e.g., CentOS, Ubuntu)

- Root access to the server

- SAPRouter software package downloaded from the SAP Support Portal

Step 1: Download SAPRouter:

Download the SAPRouter software package from the SAP Support Portal. Ensure that you download the correct version for your operating system.

Step 2: Extract the SAPRouter Package:

Transfer the downloaded SAPRouter package to your Linux server. Use the following command to extract the package:

tar -xvf saprouter_<version>_linux_x86_64.tar.gz

Step 3: Create a Directory for SAPRouter:

Create a directory to store the SAPRouter files. You can use the following command to create the directory:

mkdir /usr/sap/saprouter

Step 4: Copy SAPRouter Files:

Copy the extracted SAPRouter files to the newly created directory:

cp -R <path_to_extracted_files>/saprouter /usr/sap/saprouter

Step 5: Create a Configuration File:

Create a configuration file named `saprouter.ini` in the `/usr/sap/saprouter` directory. Here's a basic example of the configuration file:

# SAProuter Configuration File

version = 39

httpport = 81

tracefile = /usr/sap/saprouter/saprouter.trc

authid = *

permit = *

Step 6: Set Permissions:

Ensure that the SAPRouter binary and configuration files have the correct permissions:

chmod 755 /usr/sap/saprouter/saprouter

chmod 644 /usr/sap/saprouter/saprouter.ini

Step 7: Start SAPRouter:

Start the SAPRouter using the following command:

/usr/sap/saprouter/saprouter -r -R /usr/sap/saprouter/saprouter.ini

Step 8: Verify SAPRouter Status:

Verify that SAPRouter is running and listening on the specified port (e.g., 81):

netstat -tuln | grep 81

Step 9: Configure Firewall:

Configure your firewall to allow incoming and outgoing traffic on the SAPRouter port (e.g., 81) to ensure proper communication.

Step 10: Configure SAP Systems:

Update the `secinfo` file of your SAP systems to include the SAPRouter details for communication through the SAPRouter.

Overall information:

By following these steps, you can successfully install SAPRouter on your Linux server. This will help secure communication between your SAP systems and the internet, ensuring the integrity and confidentiality of your SAP landscape.

#SAP #SAPRouter #Linux #Installation SAP Young Thinkers #Red Hat Enterprise Linux SUSE Linux Enterprise Server SAP Women in Tech SAP Integration Suite SAP Business Application Studio @Muthumayandi_Yadava @Subramanian @Sap @YejinYun

RingFencing & DeCoupling S/4HANA with Enterprise Blockchain and SAP BTP - Ultimate Cyber Security 🚀

2024-05-14T13:56:58.227000+02:00

tl;dr

As part of S/4HANA Transformation Programs, Security, Accessibility, Resilience are being re-imagined.

The going in position for a lot of S/4HANA Transformation Programs includes the Cyber Security principles:

Only Employees will have direct access to the Digital Core as End Users
There will be no direct access to the Digital Core by 3rd Party Applications

The first principle, 'Only Employees will have direct access to the Digital Core as Users', decoupling the SAP system for External Users has been an architectural design pattern for more than a decade. For example, due to the extremely sensitive and confidential nature of Product LifeCycle Management Data, 13 years ago SAP were advocating, building an empty SAP PLM system in the DMZ which would use RFC's to communicate with the actual SAP PLM system in the Secure Network Zone:

The beauty of this design is that it decouples End User Access from the core SAP PLM system, therefore enhancing the security protection of the SAP PLM system.

Today's equivalent of that is to put the SAP Build Work Zone Launchpad in front of the S/4HANA Digital Core.

That is fine, that means the Digital Core is digitally decoupled for End Users, but what about Machine to Machine, Application to Application, 3rd Party Applications which want to get Data from the S/4HANA ?

Do you really want 3rd Party Companies calling APIs on your Digital Core - atkrypto.io

When a 3rd Party Company calls an API on your S/4HANA Digital Core, you are replicating your Data to that 3rd Party Company.

How can the S/4HANA Digital Core be decoupled when 3rd Party Applications need to get Data from the S/4HANA, how can the S/4HANA Digital Core be architected in such a way that there are no Machine to Machine calls directly to the S/4HANA for the purpose of getting Data ?

As elaborated in more detail in a previous blog, API's enable your Data to be replicated to 3rd Party Applications which can also be in 3rd Party Partner Companies, and this brings a set of problems centered around:

Trust between Partners: The more Partners in a Business Transaction or Business Process, the less trust there is between Partners. This is a very simple graph, as the number of Partners in a Business Transaction or Business Process goes up, so the trust between the Partners goes down. What is trust in a Business Transaction or Business Process, doing what you said you would, data, instruction, confirmation. I will deliver the parcel to the address you gave me, but what if somebody in my Team changes the delivery address for their own benefit ?

Protect the Originality & Integrity of the Data - When your S/4HANA sends the Data to your Business Partner's System we need to make sure that the Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

Replicating & Integrating the Data from your S/4HANA to your Business Partner's System and at the same time Protect the Originality & Integrity of the Data - we need to get the Data from the S/4HANA to the Business Partner's System and we need to be sure, to have surety that the Data which arrives at the Business Partner's System is the same Data as was sent from your S/4HANA. If this Data can be changed in any way, we won't be able to trust the Business Processes and Insights which are depending on that Data. And so, in the activity of moving the Data we need to make sure that that piece of Data cannot be modified or destroyed and therefore protect the originality and integrity of the Data

and it doesn't end there, it's often the case that a 3rd Party Organisation will be getting Data directly from your S/4HANA (as the Source) or posting Data to your S/4HANA (as the Target), in both cases it could be an API which through your Integration Technologies is ultimately exposed to the Internet and where the system calling the API needs to have a User on your S/4HANA.

As ever, the pattern is the same, the theme is the same,

it's all about the Data

what are the security, sensitivity, confidentiality, availability, criticality requirements of the Data

Ring Fencing S/4HANA raises the Cyber Security by reducing the attack surface.

The most secure way is with Enterprise Blockchain as a Data Ring Fence around the S/4HANA Digital Core, therefore digitally decoupling access and integration of the S/4HANA Data from other Applications.

The Enterprise Blockchain is:

. Ring Fencing of the S/4HANA

. S/4HANA does not expose API's directly to any 3rd Party Companies

. A Secure Store of Data

. A Secure Communication Channel for Data

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

The S/4HANA Ring Fencing with Enterprise Blockchain as a shared single source of truth could involve the Enterprise Blockchain running on your SAP BTP Kyma Runtime and at the same time running on Kubernetes Servers in your Business Partner's Data Center:

S4HANA RingFenced by Enterprise Blockchain S4HANA does not expose any APIs directly to 3rd Party Companies Ultimate Cyber Security - atkrypto.io

Or alternatively the S/4HANA Ring Fencing with Enterprise Blockchain could be where the Enterprise Blockchain is running on your SAP BTP Kyma Runtime and your 3rd Party Business Partner Company reads the Data from your Enterprise Blockchain on your SAP BTP Kyma Runtime as a shared common single source of truth for the Data:

S4HANA RingFenced by your own Enterprise Blockchain S4HANA does not expose any APIs directly to 3rd Party Companies Ultimate Cyber Security - atkrypto.io

Read on for the full story... 🚀

Introduction

The reason I am so interested in this is I have been securing availability and accessibility of SAP systems for the last 25 years, and back in 2013 I wrote this blog about "Alternatives for Securing Internet Facing Applications".

There is so much to talk about on this subject, let's get in to it. Back in 2013 at a Customer, we were looking at Ring Fencing critical systems.

Back then the focus was on DeCoupling the SAP system where End User access was required from people coming in from the Internet, infact the reasons for the RingFencing were centered around:

Access - Authentication & Authorisation
Storage of Data
Communication Channels
DeCoupling especially for Internet Collaboration

The DeCoupling for Internet Collaboration was based around SAP's SAP PLM Reference Architecture,

and the SAP PLM Technical System Landscape recommendation:

Fast forward to today, and SAP Customers have the luxury that the worry of securing End User Internet Access to their SAP systems is outsourced to SAP through the implementation of the SAP BTP Build Work Zone Launchpad. It should not go unnoticed that when you implement the SAP BTP Build Work Zone Launchpad Service, you also don't have to care for Web Access Firewalls and the Security of Internet Access.

But what about API's, what about System to System, Machine to Machine ? What about Integrations ? What about when Non-SAP Applications in your Company or other Companies need data from the S/4HANA ?

S/4HANA has a rich collection of API's which is always growing, but, should Applications from your Partner Companies call API end points on the S/4HANA Digital Core ?

Should 3rd Party Applications, and 3rd Party Partner's Applications be directly accessing the Digital Core S/4HANA API's ?

Regardless of whether the S/4HANA is an [Any]OnPremise, S/4HANA RISE Private Cloud Edition, S/4HANA Public Cloud Edition, should 3rd Party Applications be allowed to directly call API's on your S/4HANA ?

Let's take the S/4HANA Business Partner API, should Applications from your Partner Companies be allowed/able to call this API on your Digital Core S/4HANA to retrieve changes to Business Partner Data ?

Legacy API Integrations calling S4HANA API and Replicating Data to 3rd Party Company Applications - atkrypto.io

If you have doubts or think the answer is no, then read on, there is a solution, it is very nice, and very easy, and very secure.

One of the biggest Cyber Security threats to your Data and therefore your Operations and therefore your Business, is allowing 3rd Party Applications from 3rd Party Companies to call Data from API's on your S/4HANA Digital Core, and then, replicate your Data to Servers in their Company.

As ever, the pattern is the same, the theme is the same,

it's all about the Data

what are the security, sensitivity, confidentiality, availability, criticality requirements of the Data

Like the other blogs in this series, this blog is going to break the subject down in to three sections:

Section 1.0: The What is it of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

Section 2.0: The Why is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

Section 3.0: The How is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

In case you missed them, the previous blogs in this series are here:

Why I love SAP and Blockchain Databases and why you should too 🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain 🚀

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

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

BCP: Business Continuity Planning for SAP S/4HANA - made easy with Enterprise Blockchain 🚀

Trustable AI thanks to - SAP AI Core & SAP HANA Cloud & SAP S/4HANA & Enterprise Blockchain 🚀

IoT - Ultimate Data Cyber Security - with Enterprise Blockchain and SAP BTP 🚀

B2B Business Processes - Ultimate Cyber Data Security - with Blockchain and SAP BTP 🚀

Section 1.0: The What is it of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

What is RingFencing ? There is a very nice description here:

RingFencing is about isolating Data, away from the most important SAP system, the S/4HANA Digital Core.

DeCoupling, the word DeCoupling has a number of meanings in Enterprise IT. What we are talking about here in the case of the S/4HANA Digital Core and Data access by 3rd Party Company Applications is that we are DeCoupling the Data access away from directly on the S/4HANA, by DeCoupling we are making the S/4HANA Data indirectly accessible.

It can be thought that if we are RingFencing, or Isolating, or DeCoupling the S/4HANA Data away from the S/4HANA then we are creating another copy of the Data, another Replica of the Data, which is true, we are, and that is the same as when Data is replicated to 3rd Party Systems via API, whichever way you look at it, the ultimate goal is a Replica of the S/4HANA Data which is available and accessible to the 3rd Party Company Application for the reasons of that Application of Business Transaction.

We can replicate the Data using an S/4HANA API to the 3rd Party Company Application and lose all control of the Data and also have to deal with how to secure Authentication and Authorisation and Network Access to the API, or we can replicate to our own RingFenced isolated trusted location.

SAP S4HANA RingFenced DeCoupled Data Cyber Security Principles - atkrypto.io

What about the Enterprise Blockchain, what is Enterprise Blockchain ?

Enterprise Blockchain is:

. a Secure Store

. a Secure Communication Channel

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

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.

In these previous blogs, I made a deep dive in to what Enterprise Blockchain is and why we should be positioning it in our Enterprise Architecture:

Why I love SAP and Blockchain Databases and why you should too 🚀

SAP Enterprise Architecture: Positioning Blockchain Database as an Enterprise Technology Standard 🚀

SAP Enterprise Architecture: Let the Use Case find the Blockchain 🚀

S4HANA RingFenced by Enterprise Blockchain S4HANA does not expose any APIs directly to 3rd Party Companies Ultimate Cyber Security - atkrypto.io

and in a nutshell, Enterprise Blockchain is:

. The Digital Transformation of Information Security into Cyber Security

. The Next Generation Data Integrity, Originality, Confidentiality Protection

. Re-imagining Information Security

. Natively, out of the box, due to its special characteristics the strongest, hardest, most resilient Enterprise Database product

To wrap up this section:

. RingFencing is about isolating and protecting Data

. Enterprise Blockchain is about Cyber Security of Data

Section 2.0: The Why is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

Why would we want to RingFence and DeCouple S/4HANA, the Digital Core from 3rd Party systems which legitimately need S/4HANA Data ?

The answer is simple, Cyber Security, Cyber Threats.

Not so long ago, the focus was on High Availability and Disaster Recovery, the biggest threat was the system going down and not coming back.

Today, things have changed, and the biggest threat is a malicious actor rendering our business Data unusable.

Today we know we can buy new servers, we know we can get a Data Center up and running, but how do we repair Data which has been maliciously rendered unusable ? Think about the Ransomware attack.

So what is ring fencing and why do we need to do it ?

Ring Fencing is about reducing exposure to Cyber Threats.

What are the biggest easiest ways that we can reduce exposure to Cyber Threat ?

Stop 3rd Party Companies from calling API's on the S/4HANA Digital Core.

Stop publishing API's for 3rd Party Application access on the S/4HANA Digital Core.

Stop doing this:

Do you really want 3rd Party Companies calling APIs on your Digital Core - atkrypto.io

And what's the solution ?

The solution is the Enterprise Blockchain as the Common Data Back Bone across Companies.

Instead of replicating and sending the Data to your Business Partner, you write the S/4HANA Data to the Enterprise Blockchain.

This is like pick your own strawberries, instead of sending your Partners the strawberries, you tell your Partner the strawberries are ready and which field they are in and you let your Partners pick the strawberries themselves from the Enterprise Blockchain.

S/4HANA Data Events write the Data to the Enterprise Blockchain and S/4HANA Notification Events notify the Partner that something has happened, then, instead of calling an API on your SAP S/4HANA, the Partner then calls the API of the Enterprise Blockchain and Reads the Data from there.

The Enterprise Blockchain Database software is running on your SAP BTP Kyma Runtime and in your Partner's Servers, therefore, creating natively, out of the box, the most secure and resilient common shared single source of truth. Your have a Distributed Ledger running from your SAP BTP to the Partner's Servers.

Therefore, S/4HANA Data Event Writes to the Enterprise Blockchain as the Common Shared Single Source of Truth across the Organisations, and the S/4HANA Notification Event notifies the Partner that something has happened and that they should call the Enterprise Blockchain API to get the Data of what has happened.

And as will be explained later in the blog, it's not only about the Enterprise Blockchain being a common shared source of truth across organisations, it's about digitally decoupling the S/4HANA from 3rd Party System Integrations and gradually ring fencing the S/4HANA away from being directly accessed by 3rd Party Systems as it is today with API's.

Imagine, as described in the previous blog, when we let the Use Case find the Enterprise Blockchain, we have a Business Requirement, a Business Demand, to make Data for B2B Business Process the safest it can be, the most trustable that it can be.

When we look in our Enterprise Technology Standards, and we look for the Technology Standard in our Enterprise Portfolio which is positioned to bring the strongest protection to Data, we find the Enterprise Blockchain.

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

In the previous blogs, we have discussed in detail about the special characteristics of Enterprise Blockchain and just why it natively out of the box protects the integrity of data to a level that legacy database products cannot do, in a nutshell....

B2B Business Processes are about Data

B2B Business Processes are about the Data that goes from your S/4HANA outside the boundaries of your Company and your Network and to Partner Company's Applications and Networks and Databases.

This means B2B Business Processes are about Data and the Data depends on a Database or a Datastore

What kind of Database do B2B Business Processes Data need ? What capabilities does the Database for the B2B Business Processes Data need to have ?

1. It must not be possible to modify the Data in the Database ]- the Database needs to be immutable

2. The Data in the Database, the integrity and originality of that Data must be protected to the highest level that is technically possible

3. The Data must be available with the highest availability, the Database must be resilient to attack

4. The Database must be running simutaneously in your DataCenter and your Business Partner's DataCenter

5. S/4HANA must not expose any API's to Business Partner Companies

When we look in our Enterprise Technology Standards we find 1 Technology Standard in the Enterprise which has those capabilities, and that is..... Enterprise Blockchain

Enterprise Blockchain ticks those boxes...

Immutable - tick that box

Integrity must be protected to the highest level - tick that box, thanks to the Enterprise Blockchain Hash Mechanism and the Enterprise Blockchain Consensus Mechanism

Highest level of resilience and availability - tick that box thanks to the Distributed and Decentralised nature of the Enterprise Blockchain DeCouples S/4HANA from the process, no need to S/4HANA API's to be exposed to 3rd Party Business Partner's Applications

This is why, Enterprise Blockchain is the enabler of trustable outcomes from Enterprise B2B Business Processes.

atkrypto.io what is a blockchain

But there's more than that, B2B Business Processes can produce a lot of data, and the volumes of data can be big.

And this is why, in this blog we take the Enterprise Blockchain Technology story one level further and we introduce the:

Enterprise Blockchain Wallet

Off-Chain Data Storage

In the Enterprise Blockchain Platforms, the Enterprise Blockchain Wallet is used for Off-Chain storage of big data and in the following paragraphs we will explain why.

What is the Enterprise Blockchain Wallet, and what is Off-Chain Data Storage and why would we use them and why do we need them ?

As we have explained in a previous blog, the Enterprise Blockchain Database, the Distributed Ledger, can be looked at simply as a Database Table (which is replicated and synchronised across multiple Servers) and in principle it stores the Data like this:

Blockchain is a very simple form of database atkrypto.io

This is fine, and suited to what we call Structured Data, and as AWS nicely describe, Structured Data is information like words and numbers. This kind of data is perfectly suited to being stored in an Enterprise Blockchain Database and also a legacy Database. Examples of the data would Names, Addresses, Phone Numbers, Product Information etc.

But, Payroll can produce a lot of Data, and in large volumes which would be too big to be stored on the Enterprise Blockchain Database itself.

And that's ok, Enterprise Blockchain Platforms are ready for that, and have been designed to store both Structured Data and Data which is in files which are so big that they cannot be stored in the Enterprise Blockchain Database itself, for example the photographs from a Waste Truck's onboard camera proving that waste was responsibly tipped in the correct location and taken at the same time as recording GPS location coordinates proving the location of the Waste Truck.

So, if we can't store the large photographs files in large quantities to the Enterprise Blockchain Database, then how, in an Enterprise Blockchain Platform do we store large files of Data ?

Voila.... bring in the Enterprise Blockchain Platform Wallet. The best Enterprise Blockchain Platform products include what is called the Enterprise Blockchain Platform Wallet, or to make it shorter, the Enterprise Blockchain Wallet.

The Enterprise Blockchain Wallet enables us to store large Data, like large Files safely and securely off the chain, or 'Off-Chain'.

But if we store the large Data files Off-Chain in the Enterprise Blockchain Wallet, then how do we also have them some how on the Enterprise Blockchain Database ?

The way this works is elegant, in any decent Enterprise Blockchain Platform, the Enterprise Blockchain Wallet location is completely configurable, and could be anywhere from SAP HANA Cloud (Data Lake), or for example multiple hyperscaler object stores, such as Amazon S3, OSS (Alicloud Object Storage
Service), SAP HANA Cloud, Data Lake, and Azure Blob Storage.

The configurable Enterprise Blockchain Wallet of the Enterprise Blockchain Platform looks like this:

Enterprise Blockchain Platform - Enterprise Blockchain Wallets - Configurable Enterprise Wallets - atkrypto.io

Ok, so we've got the large volumes of Data stored in the (configurable) Enterprise Blockchain Wallet, but what about securing the Data ? Obviously the Enterprise Blockchain Wallet storage location has built in security, for example the SAP HANA Cloud, the AWS S3 Buckets, but we need more than the out of the box security of these products, the reason we are using the Enterprise Blockchain Database is because of the amazing security strengths that it natively out of the box has, and so, what about the Enterprise Blockchain Wallet, doesn't the Enterprise Blockchain Platform have some cool super hard way of protecting the data in the Enterprise Blockchain Wallet ?

Well yes it does, this is the magic of Enterprise Blockchain Database 'Off-Chain' storage in the Enterprise Blockchain Wallet. This is so unique to Blockchain Technologies.

What happens is this, when store data in the Enterprise Blockchain Wallet, the Enterprise Blockchain Platform software runs a hash algorithm over the data that we have stored and the data, and the large file gets hashed:

The data or the file in the Enterprise Blockchain Wallet gets hashed, and then, that hash is stored in the Enterprise Blockchain Database.

This means we now have a unique hash of that data or file, and if anybody or anything makes even the tiniest teeniest change to that data or file, next time we run a hash over that data or file the result will be different that the original hash which is safely stored in the Enterprise Blockchain Database and this is how we will know that the data has been changed and we cannot trust the Data and therefore we cannot use it for our Enterprise Business Processes.

On the other hand, if just before we load the data in to the SAP Enterprise Applications, eg SAP Asset Performance Management and SAP S/4HANA, from the Enterprise Blockchain Wallet, if we run a hash over the data and the hash result is the same as we have in the Enterprise Blockchain Database, then we will know we can trust the Data and we can use it in our SAP Applications and we will have trustable Data.

Enterprise Blockchain Wallet Data Hashes Stored in the Enterprise Blockchain Database - atkrypto.io

And this is why, for all of these reasons,

Ring Fencing S/4HANA Digital Core depends on Data being stored in the Enterprise Blockchain

But that's not the end of the Ring Fencing need Enterprise Blockchain.

As we showed at the beginning of the blog in this picture:

S4HANA RingFenced by Enterprise Blockchain S4HANA does not expose any APIs directly to 3rd Party Companies Ultimate Cyber Security - atkrypto.io

As the picture shows, we have an Enterprise Blockchain Database Tenant installed on a Server Host at the in your DataCenter, in your Network on your SAP BTP Kyma Service AND we have an Enterprise Blockchain Database Tenant installed on your B2B Business Partner's Network, if they are a SAP Customer then like you they can put it on the SAP BTP Kyma Service, if not they can run it on Kubernetes.

The consequence of this is that we have a distributed Enterprise Blockchain Database table which stretches from your DataCenter and Network where your S/4HANA is writing Data to it and stretches all the way across the Network to your Business Partner's DataCenter.

This means we have Ring Fenced S/4HANA with Enterprise Blockchain Data Protection from the source from your S/4HANA to the target your B2B Business Partner's It infrastructure enabling the trusted resilient reliable Business Processes to be completed.

At the same time, we are not exposing S/4HANA or the API's on the S/4HANA to any 3rd Party Applications.

We have Ring Fenced and digitally decoupled the S/4HANA Data and Access from the Business Process.

And this is why we say, Enterprise Blockchain is a Secure Communication Channel, because instead of integrating Applications sending and replicating Data across Networks, we are sharing the Data across the Enterprise Blockchain and the Enterprise Blockchain is the Secure Communication Channel.

To conclude this section, the Why to, B2B Ring Fencing S/4HANA and Enterprise Blockchain, B2B Business Process Data needs to safely replicated and trustable.

Enterprise Blockchain, due to its native super strong security strength when used as a store of Data enables B2B Business Processes to be both Secure, and Trustable.

And as we will see in the next section, it's not only about the Enterprise Blockchain being a common shared source of truth across Organisations, it's about Ring Fencing and digitally decoupling the S/4HANA and removing the attack surface from 3rd Party System Integrations and gradually ring fencing the S/4HANA away from being directly accessed by 3rd Party Systems as it is today with API's.

Section 3.0: The How is it, of RingFencing and DeCoupling S/4HANA, and Enterprise Blockchain

The goal of this blog was to show how instead of using the legacy fire and forget approach of replicating data to 3rd Party Business Partners, the Enterprise Blockchain can be deployed as a common shared single source of truth running, with an Enterprise Blockchain Tenant running close to your S/4HANA and another Enterprise Blockchain Tenant running close to your Business Partner's Application. Thus Ring Fencing and Digitally DeCoupling S/4HANA Digital Core and bringing the highest level of Cyber Security and attacked surface reduction.

In this section of the blog we will show all of the possible potential Technical Solution Architectures which will enable you to implement this next generation approach to sharing Data with the highest level of Cyber Security already today.

As described above one of the many beauties of this approach is your S/4HANA writes to the Enterprise Blockchain and your Business Partner's Application reads from the same Enterprise Blockchain. This achieves a number of things including:

. Total Control - you have total control over the Data you are sharing with the Business Partner, and you know that as long as your Business Partner's Application reads the Data from the common shared source, the Enterprise Blockchain

. Ultimate Cyber Security - then you know the maximum has been done to minimise the S/4HANA attack surface and the chance for Cyber Security risks and the maximum has been done to protect originality, integrity, and confidentiality of the Data

. S/4HANA Ring Fenced and Digitally DeCoupled from the Business Process - and on top of this, the S/4HANA has been digitally disconnected from the Business Process, because no longer do any 3rd Party Applications directly call API's on the S/4HANA

In the Technical Solution Archecture there would be two main ways for getting the data from the S/4HANA and writing it to the Enterprise Blockchain, these would be:

. API's

. Events

In these Technical Solution Architecture examples we will prioritise using S/4HANA Events to write the Data to the Enterprise Blockchain, we will be sending the Event Notification and the Event Payload, we could of course draw the same Technical Solution Architecture with API's, but we prefer the Events for the simplicity and reduced call backs to the S/4HANA and therefore making the S/4HANA more Ring Fenced and Digitally DeCoupled and therefore, enabling the S/4HANA to be protected to the higher security level and exposed to less Cyber Security risk.

Ok, let's go with the Technical Solution Architectures, in these examples we will focus on the OutSourced Payroll as the integration and B2B Business Process Example.

What do we have and what do we need:

Your Company will need:

. S/4HANA

. SAP EM and preferably SAP AEM since it has richer Security and Event Payload size capabilities and can Publish Events from Non-SAP Enterprise Applications and connect to your Enterprise Event Mesh

. SAP BTP

. SAP BTP Kyma Runtime Service - this is where the Enterprise Blockchain Container will run

. Enterprise Blockchain Platform Software which can run on Kubernetes

. If there will be larger Data objects then you will need Large Storage for Large Data and the Enterprise Blockchain Wallet in the form of SAP HANA Cloud (Data Lake)

Your Business Partner will need:

. Obviously their Payroll Application

. Either SAP BTP with Kyma Runtime, or Servers which can run Kubernetes Containers

. n.b. there is an Optional Technical Solution Architecture where you simply allow your Business Partner to read data from your Enterprise Blockchain where the Enterprise Blockchain Platform is running exclusively on your BTP, we will show that Option as well

Technical Reference Solution Architecture for SAP S/4HANA and SAP SuccessFactors and OutSourced 3rd Party Payroll Provider using Enterprise Blockchain as a Common Shared Single Source of Truth for Data and the Ultimate Cyber Data Security for B2B Business Processes...

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to Enterprise Blockchain atkrypto.io

In the next example, we have the same basic Technical Solution Architecture as the previous example, except, this Reference Use Case is ready for the Enterprise Blockchain needed to be able to handle large volumes of data and brings the Enterprise Wallet in to the picture. In the Enterprise Blockchain Platform the Enterprise Wallet storage is configurable and therefore could be SAP HANA Cloud (DataLake) or AWS S3 Buckets or other HyperScaler Data stores.

All of the other Cyber Security characteristics remain the same, S/4 is ring fenced and digitally decoupled from the Business Partner, Enterprise Blockchain is used as a common shared single source of truth for Master and Transactional Data, and the Enterprise Blockchain Tenants are running in both your DataCenter (AnyPremise) and the Business Partner's DataCenter (AnyPremise):

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to Enterprise Blockchain & Enterprise Wallet atkrypto.io

The next example Reference Technical Solution Architecture is a little bit different, let's assume, for their own reasons, your Business Partner is not going to run an Enterprise Blockchain Tenant in their (AnyPremise) DataCenter.

This is still fine, you will set up the Enterprise Blockchain Platform in your DataCenter(s) (AnyPremise) and your B2B Business Partner, in this case the outsourced 3rd Party Payroll Vendor will simply use API's to read and write to and from your Enterprise Blockchain.

All of the other benefits of the design remain the same, all of the other next generation Data sharing Cyber Security characteristics are still there, S/4 is ring fenced and digitally decoupled from the Business Partner, Enterprise Blockchain is used as a common shared single source of truth for Master and Transactional Data.

Here it is:

OutSourced Payroll Process B2B Business Processes with S4HANA and Ultimate Data Cyber Security thanks to your Enterprise Blockchain atkrypto.io

Finally, we have the same Reference Technical Architecture as above, but to be able to cater for large volumes of Data we include the Enterprise Wallet in the design.

Ok let's wrap this up, the conclusions:

Ring Fencing the S/4HANA Digital Core substantially raises the Cyber Security and reduces the attack surface for 3rd Party Attackers, Ultimate Cyber Security for Ring Fencing S/4HANA is the Enterprise Blockchain, where the Enterprise Blockchain acts a common shared single source of truth for Data across Organisations

Enterprise Blockchain is:

. Ring Fencing and Digitally DeCoupling the S/4HANA Digital Core

. A Secure Store of Data

. A Secure Communication Channel for Data

. A Common Shared Single Source of Truth in your Organisation and across Organisations

. The next generation Data Integration is about having a Common Shared Single Source of Truth

The next generation Integrations don't allow direct access to API's published in the S/4HANA and replicate Data, that's legacy, the next generation Integrations use Enterprise Blockchain as a common shared single source of truth.

The configurable Enterprise Blockchain Wallet enables you to store Big Data 'Off-Chain' and the hashes of the Data are stored safely and securely on the Enterprise Blockchain Database.

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, deep dive in to more use cases, ok, that will be 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.

All of this makes atkrypto,io the DePIN Decentralised Physical Infrastructure Network solution for Enterprise.

atkrypto is one of the Next20 startups being featured at TM Forum's DTW Ignite in Copenhagen in June

If you will be at DTW24 come and talk to us about Cyber Security of SAP Data with Enterprise Blockchain.

SAP Advanced Financial Closing (AFC) Security

2024-05-26T07:41:23.672000+02:00

Introduction

SAP Advanced Financial Closing (SAP AFC) is a solution offered by SAP to streamline and optimize financial closing processes for organizations. It provides a comprehensive suite of tools and functionalities to automate and accelerate tasks involved in the financial close process, such as reconciliations, journal entries, and financial reporting.

SAP AFC helps improve the efficiency and accuracy of financial closing activities by integrating data from various sources, standardizing processes, and providing real-time visibility into financial close status. This allows finance teams to reduce manual efforts, minimize errors, and meet regulatory requirements more effectively. Overall, SAP AFC aims to enhance the financial close process, enabling organizations to close their books faster and with greater confidence.

What are we discussing here?

Setting up security in SAP Advanced Financial Closing (SAP AFC) i.e.

Roles & users creation.
Granting access to users.

Pre-requisite:

BTP Onboarding.
User has access to BTP cockpit.

Security Activities:

Following activities/steps are carried out while setting up security in SAP Advanced Financial Closing:

Step 1: Create custom role collection

Step 2: Create user and assign custom role collection

Create users in SAP BTP for SAP AFC

Assign custom role collection to get access to tiles in SAP AFC

Step 3: Create user in SAP AFC

Create users in SAP AFC to segregate access based on Task List Creation and Task Processing.

Navigate to Manage Users tile, download the template, maintain the data and upload the file to create users into AFC

Note: File should be in .csv format

Step 4: Create user group in SAP AFC

Navigate to Configuration tile -> User Groups -> Create

Note: User group can be created via upload as well.

Step 5: Create user group in SAP AFC

Navigate to Configuration tile -> User Groups -> User-to-Group Assignment. Download the template, maintain the data and upload the template to map users to user group

Step 6: Define scoped user role

Navigate to Configuration tile -> User Roles. Create scoped roles i.e. Task to be performed (Task List Creation or Task Processing)

Select restrictions based on requirement i.e. Restricted or Unrestricted Access

Note: Restricted access won't allow user to create task but gives only display access. Also, make sure authorizations i.e. Create, Read etc. access is assigned based on the requirement.

Step 7: Manage User Role Assignments

Navigate to Manage User Role Assignments tile, select the created scoped role, click Add to assign the scoped role.

After performing above mentioned steps, user will get access to execute activities in SAP AFC.

Conclusion

Hope this article gave an insight about the activities carried out setting up security in SAP Advanced Financial Closing (SAP AFC).

List of Important Notes:

2873915 - FAQ SAP Advanced Financial Closing

Feedbacks, questions and comments are most welcome!!

Please follow my profile for future posts on SAP Security and GRC. Also, follow myself via LinkedIn

Happy Learnings!
Krishan Singh Chauhan

SAP enablement service for NIS2 Cybersecurity

2024-05-27T16:55:00.381000+02:00

NIS2 stands for the most expansive Cybersecurity directive in Europe to date and regardless if you RISE or GROW with SAP, Cybersecurity remains critical and satisfying regulations a challenge.

Learn how to navigate current security measures in your SAP landscape and to identify potential gaps.
Obtain guidance on aligning Cybersecurity measures with this new regulation and how to implement standards-based Cybersecurity management.

Key Takeaways

The EU's NIS2 Directive is a revised version of the existing Network and Information Security (NIS) Directive. It was officially signed and published in December 2022. The "Gesetz zur Umsetzung von EU NIS2 und Stärkung der Cybersicherheit" (NIS2UmsuCG) transposes the directive into German regulation, getting effective October 2024.
The NIS2 Directive expands the scope and sharpens the requirements for Cybersecurity through structured requirements for security processes, technical and organizational measures, and reporting obligations.
The NIS2 Directive introduces stricter penalties for violations.
The implementation of an Information Security Management System (ISMS) facilitates the execution of the NIS2 Directive.
SAP supports its customers in preparing for the NIS2 Compliance of their SAP systems and cybersecurity processes with dedicated consulting services.

EU NIS2 – Network and Information Security in the European Union

NIS2 is designed to address the shortcomings of its predecessor, NIS, particularly in terms of discrepancies among member states regarding the implementation and requirements of cybersecurity measures. This updated directive has a broader reach and enhances NIS.

The directive aims to protect important sectors and services from Cybersecurity threats. Institutions that meet the thresholds defined in the directive, such as electricity and water plants or banks, must comply with legal requirements to make their systems and networks more secure. The European Union (EU) Member States must transpose the NIS2 directive into national law. In Germany, the directive is transposed into German regulation via the "Gesetz zur Umsetzung von EU NIS2 und Stärkung der Cybersicherheit" (NIS2UmsuCG)“, effective October 18th, 2024.

In short, NIS2 is responsible for the following key modifications:

The applicability scope has been extended to incorporate sectors such as telecommunications, social media platforms, public administration, and the food sector. NIS2 also includes subcontractors with access to critical infrastructure, recognizing the significant implications of infrastructure threats that could potentially compromise the security of an entire organization.
Introduction of a size cap, whereby medium to large entities (with over 50 employees and an annual turnover exceeding €10 million) in the relevant sectors will be subject to NIS2.
An increase in sanctions to a maximum of 10 million EURO or 2% of the total annual global turnover, mirroring the level of GDPR fines.

The NIS2 directive impacts approximately 160.000 organizations in the EU due to the expansion in the number of sectors defined by the directive. NIS2 differentiates between "essential" and "important" sectors:

For the first time, NIS2 introduces the concept of "important facilities", broadening the scope of the critical infrastructure. As a result, companies in sectors such as digital marketplaces or the food industry now also fall under the NIS2 directive. In Germany, the legislature estimates about 30,000 companies will be affected by NIS2, with "important institutions" making up over 20,000 of these companies.

Challenges for Businesses

NIS2 heightens the requirements for companies. There are four main areas to comply and to ensure security on an organizational level:

Risk Management: Organizations need to take measures to minimize cyber risks. It includes enhanced network security, incident management, strong access control, and encryption.
Corporate Accountability: Management must oversee, approve, and be prepared to address cyber risks when needed. Breaches might result in different penalties for management, which can potentially become a temporary ban from management roles.
Reporting Obligations: Essential and important entities must have processes to report security incidents with a significant impact on their services. NIS2 can set notification deadlines: For instance, initial threat notifications must be made within 24 hours of identifying an incident, with further updates required within 72 hours.
Business Continuity: Organizations must have a plan to show how they ensure business continuity in case of major cyber incidents. It is important to include considerations about system recovery, emergency procedures, and having a crisis response team.

NIS2 minimum measures to address Cybersecurity threads

Beyond the four primary areas of requirement, NIS2 mandates that essential and important entities establish baseline security measures to counter potential types of cyberthreats. The following are among these:

Risk management procedures and security policies for information systems.
Policies and procedures for evaluating the effectiveness of security measures as well as policies and procedures for the use of cryptography.
A strategy for managing and mitigating security incidents and for managing business operations during and after a security incident.
Supply chain security and company-supplier relations require tailored security measures for each supplier, followed by an overall security assessment.
Cybersecurity training and a practice for basic computer hygiene.
Security measures around the acquisition, development, and operation of systems. It also necessitates having procedures for handling and reporting vulnerabilities.
Security procedures for employee access to confidential or critical information must be established, which includes data access policies. It's also essential for concerned organizations to maintain an inventory of all pertinent assets, ensuring their appropriate use and management.
The use of multi-factor authentication, continuous authentication solutions, voice, video, and text encryption, along with secure internal emergency communication, when appropriate.

SAP enablement service for NIS2 Cybersecurity

SAP offers a SAP Store Service to interactively delve into the potential impacts of NIS2 requirements on SAP landscapes, utilizing S/4HANA as an illustrative case study. During this interactive session we present our viewpoints on Cybersecurity Compliance:

Cybersecurity Architecture point of view

The objective to secure business processes in your SAP landscape end-to-end, leveraging all relevant capabilities of SAP’s Cybersecurity and Compliance solutions and services.

Cybersecurity Compliance & Assurance point of view

The need to adhere to Cybersecurity regulations, hence to rely on standards-based security and control management as well as auditing and monitoring your SAP landscape.

Cybersecurity Assessment point of view

The desire for detailed insights into the Cybersecurity as-is situation, induced by uncertainty surrounding the current measures in the SAP landscape and the fear of "open flanks".

A service available in SAP Store

Find out what EU NIS2 Article 21.2 (i) has to do with ABAP profile parameter rfc/selftrust and learn more about the related SAP Customer Success service offering in SAP Store: https://store.sap.com/dcp/en/

About the Author
Oliver Derksen, CISA, M.A. Risk and Compliance Management
Principal Consultant Information Security Management and Integrated Assurance
Success Delivery Center DTS Cybersecurity & Compliance | cscm4s-service@sap.com

New CIO Guide: Identity Lifecycle in SAP Landscapes

2024-06-04T13:27:48.243000+02:00

We just published our new, comprehensive CIO Guide: Identity Lifecycle in SAP Landscapes!

This new CIO guide explores the SAP approach to identity and access management (IAM) in the context of the identity lifecycle. It explains how IAM software from SAP supports building successful system integrations in cloud and hybrid environments and includes diagrams and a reference architecture to illustrate the concepts. With SAP Cloud Identity Services and well-established IAM-related industry standards, SAP improves system integration and helps provide a seamless user experience while also improving security and compliance.

The first version of this CIO guide was released in 2018 and quickly became one of the most popular documents in the SAP security community. Despite an update of the guide in 2021, a lot has changed again since then, so we decided to issue another update that builds on the proven format while adding new technical developments and strategic recommendations.

The most important change is that we have brought the capabilities of authentication, authorization, and provisioning together into one seamless solution, SAP Cloud Identity Services. At the same time, the Identity Directory service has assumed a much more prominent role as the backbone of IAM tools and processes.

The new guide explains the identity lifecycle and the SAP Cloud Identity Services strategy and explores the SAP offerings for each area. We also introduce a section on the reference architectures for IAM to provide you with an overview and comprehensive technical diagrams for the major IAM areas of authentication, identity lifecycle, and authorization.

Read the new CIO guide!

For more information about SAP Cloud Identity Services and to stay up to date on the latest developments, visit our topic page in SAP Community:

https://pages.community.sap.com/topics/cloud-identity-services

Boosting SAP Netweaver Security: A Guide to Integrating SAP Netweaver (ABAP Stack) with IBM Verify

2024-06-13T08:10:17.838000+02:00

Introduction

Effective user provisioning is essential for both organisational security and productivity in the context of digital operations. But controlling user access across many systems can be complicated and difficult at times. This blog article will discuss how IBM Verify SaaS integrates seamlessly with SAP NetWeaver and explain how this works together to improve overall operational efficiency, strengthen security, and streamline user provisioning processes.

SAP NetWeaver (on-premise) is a widely used platform that acts as the foundation for various SAP applications, including SAP ECC and S/4HANA. Users typically log in to these applications through the SAP NetWeaver interface.

IBM Security Verify SaaS adds an extra layer of security to the login process for SAP ECC and S/4HANA systems. By integrating with SAP NetWeaver, it allows users to log in securely using a web browser, but also requires an additional verification step (Multi-Factor Authentication or MFA) provided by IBM Security Verify. This MFA could be a code from a mobile app, a fingerprint scan, or another secure method.

SAP Netweaver on ABAP Stack vs SAP Netweaver on Java Stack

Development stacks for Java and ABAP are provided by SAP NetWeaver. Java offers open-source flexibility and meets the demands of contemporary development, while ABAP excels in fundamental business logic and connects with SAP with ease. Select Java for modern apps, scalability, and a larger talent pool, or ABAP for deep integration and current SAP expertise. Although it's less prevalent, both allow interoperability and can coexist on a single server.

While IBM Security Verify offers an adapter for integrating with SAP NetWeaver applications on the Java stack, this blog focuses specifically on the integration process for SAP NetWeaver applications built on the ABAP stack with IBM Security Verify SaaS.

Architecture

IBM Security Verify SaaS can be integrated with a hybrid SAP landscape, including on-premise SAP Netweaver, cloud-based SAP BTP, and other SAP SaaS offerings (such as SAP SuccessFactors, SAP ARIBA, SAP Fieldglass). This centralized approach offers strong security with Multi-Factor Authentication and simplifies user experience through Single Sign-On. Users authenticate through IBM Security Verify, which then communicates with the relevant SAP application (Netweaver, BTP, or SAP SaaS offering) to grant access. This architecture enhances security and streamlines user experience for accessing SAP resources.

Prerequisites

SAP NetWeaver
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 NetWeaver

IBM Security Verify Configuration :

You will be navigated to the home screen, as displayed below, after logging in.

Now, follow these steps:

On the left panel, click "Applications" under "Applications."
On the right side of the screen, click the "Add application" button.
In the default applications list, search for "SAP NetWeaver" instead of creating a custom application.

As indicated below, complete the "General" section with the relevant information, then save it.

Select the "Sign on" tab and complete the fields as indicated by the screenshots below. The required data is available through your individual SAP NetWeaver account. Furthermore, adhere to the conditions listed in “Prerequisites” in order to receive the necessary information from SAP NetWeaver.

Now we need to upload "Metadata" file into SAP Netweaver which we can download from IBM Verify dashboard as mentioned in below steps.

Go to "Sign on" section of the application and scroll on the right side of the screen where you can find prerequisites
Scroll down as mentioned on below screenshots to the download metadata step and click on the link.
The metadata file will be saved to device which you can upload to in SAP NetWeaver Cloud as highlighted below:

Refer to SAP Netweaver user details to create a user in IBM Security Verify. Follow the instructions outlined below.
1. Log in to SAP Netweaver via SAP GUI.
2. Navigate to transaction code "SU01D".
3. Choose the user for whom you want to create details in IBM Security Verify.
4. Gather user information, including first and last names, email addresses, etc.

For reference see below screenshot:

As we have completed the configurations in IBM Security Verify. Now, let's add a user with the appropriate attributes in IBM Security Verify and check if it maps to the SAP NetWeaver dashboard.

Go to the "Users" tab under the "Directory" section on the left side of the IBM Security Verify dashboard.

Click on the "Add User" button as shown in the screenshot below.

Complete all required fields in the user information section depicted in the image below, then proceed to click on the "Save" button within the user tab interface.

Navigate downwards to access additional fields for adding further details about the user. In the provided screenshot, you can observe that we have included the email address for the user.

After completing the necessary user details, proceed to click on the "Save" button to ensure the user information is stored. Set up the SAP Netweaver configuration and then access the SAP NetWeaver application to ensure that the newly formed user is correctly mapped within the system.

SAP Netweaver Configuration

Establish a local SAML 2.0 provider: Enter into the SAP Netweaver login page using SAP GUI. Here, access the transaction "SAML2" by navigating to the command field at the top of the screen, as indicated below:

A web browser configuration screen will be displayed, requiring you to choose "Create SAML2.0 Local Provider" and press the "Next" button.

Enter "IBM_Security_Verify" as the provider name in the Initial settings.

Click "Next" since there is no need to modify the options in the "General Settings" box.

Select the "Finish" option, we'll leave the "Service Provider Settings" as they are by default, as seen below.

You will now be taken to the screen below, where you can see the details that you customised in accordance with the previous instructions.

Upload Metadata File: As indicated below, click the "Trusted Providers" section. Then, click the "Add" button to bring up a drop-down menu, from which choose "Upload Metadata File" and upload the file which was downloaded from IBM Security Verify to local device.

There should be a new line item shown in the trusted providers list. You can configure in the "Endpoints" area as seen in the screenshot below.

Click "Add" after selecting the "Identity Federation" section, then enter the user's email address under "Supported NameID Formats". Additionally, as seen in the screenshot below, set "Email" as the User ID mapping mode and “email” for the "Assertion Attribute Name" field.

The following step will take us to a different section called "Signature and Encryption" where we will check the value of "Digest Algorithm" and, if it isn't already, set it to "SH-256". We will also check the values of the remaining fields, as indicated in the screenshot below:

We'll now select the "Authentication Requirements" option and review the default settings as shown below:

Include a policy for web applications: To access "Policies," follow the instructions in the screenshot below. After choosing "Web Applications Policies" press "Add".

Name the policy "SSO" and describe it as such. And confirm the information as displayed in the screenshots below:

Let’s test :

Use the web browser to log in to SAP Netweaver as shown below. Please be aware that in order to access SAP Netweaver on a web browser, you must utilise a login link.

Here, I’ll use the IBMid for further login into the system.

Give your IBMid and click on “Continue”.

Select “w3id Credentials” as below :

Give your username and password details and click on “Sign in”.

You should be able to access the SAP Netweaver as below in your web browser.

Conclusion

The integration of IBM Verify with SAP NetWeaver presents a powerful synergy that not only simplifies user provisioning but also fortifies organisational security and enhances operational efficiency. By combining the robust authentication features of IBM Verify with the versatile platform of SAP NetWeaver, businesses can streamline user access management, reduce manual effort, and bolster security measures. This integration not only ensures compliance and consistency but also elevates the overall user experience. As organizations navigate the complexities of the digital landscape, leveraging this integration can provide a competitive edge while effectively managing user identities and access controls.

More information:

IBM Security Verify

Blog for setting up Multi factor authentication using IBM Verify

Blog for setting up Password less MFA using IBM Verify

SAP BTP Trust and federation with identity providers

Streamlining User Provisioning from IBM Verify to SAP Cloud Identity Services

Integrating IBM Security Verify with SAP Cloud Identity Services in SAP BTP

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

SAP BTP Global Account, Directories and Subaccounts

2024-06-18T16:04:45.762000+02:00

SAP BTP Cockpit

Start the SAP BTP cockpit

https://cockpit.btp.cloud.sap

Big Picture and Overview

How you can structure your SAP BTP account

Go to Account Explorer

Here you can create "Directories" and "Subaccounts"

Possible structures are:

by country/region
by department
by project
etc.

Example

As a simple example I use a headquarter in Switzerland and a branch in Italy.

Now you can configure additional functions for the relevant areas.

SAP BTP Role Templates, Roles and Role Collections

2024-06-20T08:40:15.861000+02:00

SAP BTP Big Picture for Role Templates, Roles and Role Collections

Role Templates: Roles for a specific Application, defined by a Developer.
Role: Classic single Role with rights.
Role Collection: A collection of single roles.

SAP BTP Cockpit - User Management

In the SAP BTP Cockpit you find this section under "Security"

Create a new Role Collection

Create a new Role Collection, for example for Key Users of an Application

Select the relevat Roles ad add them to the Role Collection

Now it should look like this

Click "save"

Assign Role Collection to a User

Now you can assign the newly created Role Collection to a User

Finally it looks like this

Safeguarding Enterprise Personal and Financial Data in SAP HANA with IBM Security Guardium

2024-07-01T11:41:50.926000+02:00

Introduction

In the modern digital world, protecting sensitive business data is more important than ever. SAP HANA Cloud databases, known for their high performance and advanced analytics, serve as essential to many organisations' operations. However, the huge amounts of personal and financial data they handle make them potential targets for cyber-attacks. Implementing advanced security measures is critical for protecting these datasets from any possible breaches.

This blog explains how IBM Security Guardium offers an additional level of safety to SAP HANA Cloud databases. You can ensure that enterprise personal and financial data is secure and meets regulatory standards by leveraging Guardium's complete capabilities. Learn how this powerful combo may improve your data security strategy and safeguard your company's most precious assets.

Importance of Data classification and identification for Data security

Identifying and classifying data is crucial for maintaining data security and ensuring compliance with regulatory standards. It helps in understanding the sensitivity and value of data, enabling organisations to implement appropriate security measures. Proper classification aids in protecting sensitive information from unauthorised access and potential breaches, while also facilitating efficient data management and retrieval.

About this blog

In this blog, IBM Guardium can be utilised to discover sensitive data within an SAP HANA DB. By scanning the database, Guardium identifies and classifies sensitive information, such as personal data, financial records, and intellectual property. Once discovered, this data is added to specific groups of fields or objects for continuous observation. This grouping facilitates targeted monitoring and protection, ensuring that sensitive data is safeguarded against unauthorized access and potential breaches. Guardium's scanning and classification capabilities help maintain data security and compliance with regulatory standards for data protection in SAP HANA environments.

Prerequisites

SAP BTP Account with access to SAP HANA Cloud Database
IBM Security Guardium

Architecture

SAP HANA Cloud, a cloud-based version of the SAP HANA database, offers a multi-model platform for storing and processing diverse data. It integrates with SAP S/4HANA, the latest ERP suite, and SAP Business Technology Platform for application development. SAP HANA itself has a comprehensive set of security measures to ensure data safety. Additionally, security is further enhanced through IBM Security Guardium. IBM Security Guardium will scan the SAP HANA Cloud DB for the identification and classification of sensitive data such as personal details, financial details ... etc. This data classification will enable administrator to keep an eye on specific table fields and help them formulate further business strategies such as data masking of data hiding for the database for the security purpose. Hence, this architecture positions SAP HANA Cloud as a secured and strong foundation for building versatile cloud-based enterprise applications.

Steps for integration

Go to the Discover button on the left-hand panel, open the "Classification" dropdown, and select "Datasource Definitions" as shown below:

Click the "New" button, as highlighted below:

Enter details such application type, name, database type and other details in the pop-up screen as shown below:

Please keep in mind that the username and password for the SAP HANA Cloud database must be entered here.

Disclaimer: SAP does not recommend their customers to use the DBADMIN user for daily tasks. Please note that the DBADMIN user is used only for demonstration purposes. Refer to SAP User Management.

To obtain the host name/IP address and port number, log into your SAP BTP account and click to the space for which you want to integrate Guardium with SAP HANA Cloud DB.

Disclaimer: For enhanced security, SAP recommend their customers to adhere to user connect restriction policies. More details on these policies can be found here: SAP HANA Cloud Database Security Guide - Connect Restrictions. This is an important feature that customers should utilise.

Select "SAP HANA Cloud" as indicated below:

Now, click "Actions" and choose "Copy SQL Endpoint".

Securing public endpoints is a significant concern for customers. It is relevant to note that SAP HANA Cloud will support these endpoints in the near future.

Product Vision roadmap entry for all Platform-as-a-Service (PaaS) support across hyperscalers: SAP Roadmap
2023-Q4 support for AWS Private Link (PL) connections to HC HDB SQL Endpoints: SAP Roadmap
2023-Q4 support for AWS PL connections to both HDLRE SQL Endpoints and HDLFS REST Endpoints: SAP Roadmap

Paste the copied SQL endpoint and receive the hostname/IP data as shown below:

And get the port number details displayed follows from the same:

To check the status of your connection, click the "Test Connection" button.

The SAP HANA Cloud database setup is now complete. You can see the details as follows:

Click the Discover button on the left-hand panel, then open the drop-down menu by clicking "Classification" and selecting "Discover Sensitive Data". Refer to the image below.

On the following screen, select "PII [template]". Check out the information as recommended below, then click "Roles" to assign them, and then click the "Next" button.

Select the check box for the template pattern you wish to include (for example, birth date, city) and click the "Copy" button as displayed below and click on “Next” button:

Once we've completed "What to discover," we'll go on to "Where to search" and choose the integrated SAP HANA Cloud database and click on “Next”.

"Run discovery" is a convenience feature that allows you to conduct classification and check the status. Click "Next".

We are now in the "Review report" stage, where we select a list of fields and select "Add to Groupof Object/Field" from the "Add to Group" drop-down and click on the “Next” button.

Select group “SAP Sensitive Data” and click on the “OK” button.

Let’s Test

Click the "Setup" button on the left-hand panel and choose "Group Builder" from the "Tools and Views" drop-down list.

Select "Object/Field" from the "Action" drop-down, then select "SAP Sensitive Data" from the list. Click the "Edit" button.

In the pop-up screen, select "Members".

You will be able to see the relevant personal and financial table and fields from SAP HANA Cloud database.

Now that you identified and categorised that sensitive data in your HANA database, IBM Security Guardium can further help to improve data security by adoption of specialised security measures, such as to

- Add encryption or access controls, to safeguard important data from unauthorised access and breaches; or by

- Masking or blocking data access requests that violate regulations or policies

- Configuring alerts for unauthorised access attempts, e.g. if someone from a non-finance department tries to access financial data, an alert can be triggered.

In general, classifying data based on its sensitivity in the first place helps to increase visibility and in turn to comply with regulatory obligations (e.g. by generating detailed reports for audits), prevent data loss, and reduce risks associated with data misuse. These features ensure that data handling procedures are consistent with organisational rules and legal standards, hence improving overall data security.

Conclusion

Securing SAP HANA Cloud databases is critical for safeguarding company personal and financial information from evolving cyber threats. SAP HANA Cloud offers a robust set of security features. More information on these security measures can be found in the SAP HANA Cloud Security Guide.

IBM Security Guardium complements the existing security capabilities of SAP HANA Cloud by providing additional data protection, continuous monitoring, and compliance features. This enhancement can be particularly valuable for customers seeking extra layers of security or specific functionalities that they feel are necessary.

Investing in advanced security measures like IBM Security Guardium not only protects essential data but also demonstrates your company's strong commitment to data privacy and compliance. As cyber threats become more sophisticated, leveraging IBM Security Guardium in conjunction with SAP HANA Cloud's comprehensive security offerings is a proactive step toward strengthening your database's security posture and ensuring the integrity and safety of your company data.

IBM Security Guardium provides enterprise data protection for a variety of databases and data sources, and with the HANA integration, it incorporates it into a corporate-wide data security concept.

More Information

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

Integration of SAP Task Center, Azure and ServiceNow - SSO, User Provisioning and Token exchange

2024-07-19T16:10:57.124000+02:00

During the configuration of Task Connect, an integration between ServiceNow and SAP Task center, we devoted significant effort to addressing security concerns, particularly focusing on user authentication and user provisioning. Given the widespread use of Azure as an identity and token provider, we developed a method to synchronize users and groups across ServiceNow, SAP Task Center, and Azure.

In this document, you will find the scenario overview, related architectural diagrams presenting the different components and how they interact with each other and what are the steps to follow to configure the connection between ServiceNow, SAP Task Center and Azure.

1. Scenario overview

The starting point in this scenario is the user's authentication and access token issued by the SAP Cloud Identity tenant's authentication service (IAS), indicated as AT (IAS) APP in returned by step 2 in figure 1 below and following the notation <token type> (<issuer>) <audience>. The complete token exchange is orchestrated by the OAuth 2.0 and OpenID Connect (OIDC) authorization and authentication frameworks and their respective token types, which are access tokens (AT), refresh tokens (RT), and identity tokens (ID). Thus, AT (IAS) IAS is an access token, issued by the IAS tenant's OAuth 2.0 authorization server, with an audience set to the IAS tenant's client ID. All tokens except for refresh tokens are formatted as JWTs. Compared to the token exchange in the previous parts of this blog series (see part I, Interoperability and standards, for more details), SAML 2.0 - or more precisely the SAML assertion as an OAuth 2.0 authorization grant defined in section 2.1 of RFC 7522 - is no longer used in this scenario. Instead of transforming between different token formats (JWT to SAML and back to JWT), this scenario only uses JWTs for the token exchange. It is important to note that for this token exchange no direct trust relationship between the application on BTP and Azure AD is required. The application only has a trust relationship to the IAS tenant, and the IAS tenant maintains the trust relationship to the Azure AD tenant (and vice versa).

All authentication requests for the business application on BTP (SAP TASK CENTER) are forwarded by the IAS tenant to the Azure AD tenant which is configured as a corporate identity provider (IdP) in IAS. IAS acts as a proxy and delegates authentication to Azure AD in the role of the relying party to the corporate identity provider. The IAS tenant therefore requires an application registration in Azure AD.

Note: For the TaskConnect integration configuration to work, the SAP Task Center should be configured according to the following documentation: https://help.sap.com/docs/task-center/sap-task-center/initial-setup

2. Users authentication and token exchange

The user accesses the BTP business application's SAP Task Center. The app delegates authentication to the IAS tenant using OIDC. It starts the authentication process by redirecting the user' browser to the IAS tenant's OAuth server authorization endpoint at https://<IAS tenant name>.accounts.ondemand.com/oauth2/authorize and sending an OAuth authorization request.
Because the user is not yet authenticated at the IAS tenant, the user's browser is redirected to the IAS tenant's single sign-on (SSO) endpoint at https://<IAS tenant name>.accounts.ondemand.com/saml2/idp/sso.
The business application is configured in IAS to pass all authentication requests to Azure AD as its corporate IdP. Therefore, IAS sends an OAuth authorization request to the Azure AD tenant's OAuth authorization endpoint.
The user gets prompted by Azure AD to enter the credentials. Upon successful authentication, Azure AD sends the authorization code to IAS by redirecting the user's web browser to the URI specified in the previous request.
IAS receives the authorization code and sends an access token request to Azure AD's token. Azure AD issues an access token and refresh token (RT(AAD)IAS which is cached for later use in step for the authenticated user with an audience set to the IAS tenant's OIDC name.
The BTP business application requests a client assertion from the IAS tenant to use it in the subsequent requests for the token exchange via the IAS tenant's OIDC proxy. The client application sends a token request to the IAS tenant's token endpoint. The POST request is authenticated with the client ID and secret of the business application in IAS. The client assertion from IAS takes the form of a signed JWT that proofs the application's identity to AAD when requesting tokens via the IAS corporate IdP OIDC proxy.
The business application exchanges the IAS-issued ID token into an Azure AD-issued access token via the IAS tenant's OIDC proxy token exchange endpoint. The POST request uses the assertion parameter to pass the base64-encoded IAS ID token of the user.
IAS token service sends a refresh token request using RT(AAD)IAS cached in step 5 to obtain a new access token AT(AAD)APP for the business application,
The business application uses the Azure AD On-behalf-Of (ObO) flow for requesting the access token
Finally, the business application calls the ServiceNow to take actions to the signed-in user's tasks.
ServiceNow validate the token using OIDC provider to verify ID tokens configuration with the same application registered in Azure which issues an access token and refresh token in step 5.

3. User provisioning - Azure SAP

Use SAP Cloud Identity Services - Identity Provisioning to provision users from Microsoft Azure Active Directory to SAP Cloud Identity Services - Identity Authentication.

4. User provisioning & SSO - Azure-ServiceNow

Use ServiceNow enterprise application in Azure to provision users from Microsoft Azure Active Directory to ServiceNow instance
Use the same ServiceNow enterprise application created in step 13 in Azure to authenticate users from Microsoft Azure Active Directory to ServiceNow instance

5. Technical service flow

You need to create integration user for SAP Technical connection and choose how SAP Task Center will authenticate when technical connection is used (delta jobs in SAP are using this technical connection)

For example, you can use Basic Auth or OAuth:

For basic auth provide username and password to the team who is configuring the connection to ServiceNow.
The BTP business application requests a client assertion from the IAS tenant to use it in the subsequent requests for the token exchange via the IAS tenant's OIDC proxy.
For OAuth follow these steps in ServiceNow (account with admin role is required)
1. Open System OAuth -> Application Registry. Click New and choose "Create an OAuth API endpoint for external clients". Configure the record and share username, user password, client id and client secret with the team configuring the connection to ServiceNow

6. Register the applications in Azure AD for IAS tenant and SN OIDC provider to verify ID tokens.

The token exchange and OIDC proxy setup between the SN, IAS, and the Azure AD tenant, requires a trust relationship which is established by registering one application in the Azure AD tenant

“SAPIASTenant” represents the SAP Cloud Identity Service tenant.

Step 1
Login to Azure Portal (e.g. with your Microsoft 365 E5 developer subscription’s admin account) and select Azure Active Directory from the portal menu.

Select App registrations from the left-side menu.

Step 2
Click + New registration

Step 3
Enter "<SAP IAS Tenant>" for the Name of the new application registration.

Replace <SAP IAS Tenant> with your friendly name

Select "Web" from the dropdown list in the Redirect UR I section.

Enter your IAS tenant's redirect UR Iin the Redirect URI section's text field:https://<IAStenant name>.accounts.ondemand.com/oauth2/callback.Replace <IAS tenant name> with your tenant's name.

Click Register.

Step 4
Copy the newly generated Application (client) ID to a temporary text file. You will need it in the next step for deploying the sample application.

Step 5
Select Manifest from the navigation menu to edit the application registration's manifest file.
Change the value for the field "accessTokenAcceptedVersion" from null to 2.
Click Save.

7. Configure trust to the IAS tenant in Azure AD

Trust to the IAS tenant is configured in Azure AD with a new federated identity credential. In addition, a client secret is required for the initial token exchange in step 5 of figure 1. Both credentials will be configured for the application registrations in the following step.

Step 6
Select the SAPIASTenant app from the list. (created in step 3)
Select Certificates & secrets from the menu and switch to the Client secrets tab.
Click + New client secret.

Step 7
Enter "<SAPOIDCProxy>" for the Description.
Click Add.

Step 8
Click Copy to clipboard in the Value column and paste it to a temporary text file. You will need it later in the setup process.

Step 9
Create another one secret for ServiceNow
Enter "<ServiceNow>" for the Description.
Click Add.

8. Configure permissions and scopes in Azure AD

To request the Outlook calendar event on behalf of the user, the business application (SAPBTPGraphApp) requires the Graph API permission Calendars.Read. SAPBTPGraphApp also exposes the custom scope "token.exchange".This scope is referred to as a (downstream) API permission for the SAPIASTenant application registration and required for steps 7 and 8 in figure 1. For the initial token request to Azure AD (see step 5 in figure 1 and figure 2), the SAPIASTenant application exposes the custom scope "ias.access".

Step 10
Go to Expose an API in the navigation menu.
Click + Add a scope.

Step 11
Accept the default value for the Application ID URI.
Click Save and continue.

Step 12
Enter "ias.access" for the new Scope name. Provide an Admin consent display name and description.
Click Add scope.

Scope name:
ias.access

Admin consent display name:
IAS Tenant Access

Admin consent description:
Access to SAP Cloud Identity service Application

Step 13
Copy the full-qualified URI of the new scope (api://<client id>/ias.access) from the clipboard to temporary text file. It will be used in a later setup step.

Step 14
Add Optional claim to the token.
Navigate to Token configuration
+ Add optional claim
Token Type - ID
Select "email" and add

Step 15
If message about API permissions required appear
select the checkbox - Turn On Microsoft Graph email permission (required for claim to appear in token)
Click "add"

Step 16
Grant Admin Consent

Step 17
Navigate to authentication
Scroll down to Implicit grant and hybrid flows
Select the tokens you would like to be issued by the authorization endpoint:
Select the checkbox ID tokens
Click Save

9. Configure Azure as an OAUTH OIDC provider on ServiceNow

Step 18
Open the ServiceNow instance
Navigate to All > System OAuth > Application Registry.
Click New, click Configure an OIDC provider to verify ID tokens.

Step 19
Fill the form.

Field	Description
Name	A unique name that identifies the OAuth OIDC entity.
Client ID	The client ID of the application registered in Azure in step 4. The instance uses the client ID when requesting an access token.
Client Secret	The client secret of the application registered in Azure in step 31.
OAuth OIDC Provider Configuration	The OIDC provider (ADFS, Auth0, Azure AD, Google, Okta) can be used to validate the JWT token. Click the record of your OIDC provider configuration to validate the User Claim and User Field are set appropriately. If you check Enable JTI claim verification, the ServiceNow JWT token validation also validates the JTI sent by the provider. See next step for more details
Clock Skew	The number, in seconds, for the constraint to be considered valid. The default is 300.
Comments	Additional information to associate with the application.
Application	The name of the application containing this entity.
Accessible from	Select an option to make it accessible from all application scopes, or this application scope only. (all scope by default)
Enforce Token Restrictions	Select to only allow tokens to be used with APIs set to allow the authentication profile. You can set grant access using an API access policy. For more information, seeCreate REST API access policy. Default: Unselected.
Active	Select the check box to make the OAuth application active.
Redirect URL	The URL of the OAuth application for receiving the authorization code. (automatically added when save the application
End Session Endpoint URL	The URL endpoint which enables after a session ends.(not required
Enable force authentication	Option to enable force authentication for users. (not required)

Step 20
OAuth OIDC Provider Configuration
Click on the search icon and then New

OIDC Provider - A unique name that identifies the OIDC provider

OIDC Metadata URL - the OIDC provider OpenID Connect metadata document (details in next step)

User claim: email
User Field: the field in SN which contain mail value

Enable JTI claim verification: Disable

Step 21
Navigate to azure application which created in step 3 - Overview - Endpoints - OpenID Connect metadata document

Step 22
Navigate to Oauth Entity Scope and add
offline_access,
Open id

Click Update.

Step 23
Navigate to the Oauth Entity Profiles which is automatically created when Save Oauth OIDC entity.

Verify that the Grant type is is Resource Owner Password Credentials and then add the OAuth Entity Scopes created in the above step.

Step 24
Add Auth Scope:
useraccount

Step 25
Navigate to the created in step 34 Oauth OIDC Entity and copy the redirect url

Step 26
Navigate to Azure App registered in step 3
Authentication
Add the url from the previous step. (do not remove or replace the url added in step 3 when create the application)
Save

10. Setup user provisioning - Azure >> SAP

Step 27
Launch a browser window and access your Azure portal using the URL: https://portal.azure.com/.

You will need to authenticate to your Azure AD using your admin credentials.

Step 28
Click Microsoft Entra ID.

Step 29
Click App Registration >> New registration.

Step 30
Specify a name for your app and click Register

Step 31
Click API permission >> Add a permission.

Step 32
Select Microsoft Graph.

Step 33
Click Application permissions.

Step 34
From the list of API permissions, expand User and select User.Read.All.

Step 35
From the API list also select Group >> Read.All and Directory >> Read.All. Click Add permissions at the bottom of the screen once done.

Step 36
The permissions are not granted by default. To grant the permissions, click Grant admin consent for Default Directory.

Step 37
Click Yes on the popup message and confirm that all permissions are granted.

Step 38
Click Overview from the left panel. Make a note of the Application (client) ID. You will need this later when creating the source system in IPS. Click Add a certificate or secret.

Step 39
Click New client secret.

Step 40
Specify a description and expiry time for the client secret.

Step 41
You should have client secret added successfully. Make a note of the value field as you will need it later when creating the source system in IPS.

Step 42
Navigate to the main overview page of Azure AD and make a note of your Primary domain. You will need this value when creating the source system in IPS.

Step 43
Follow the blog https://community.sap.com/t5/technology-blogs-by-sap/provision-users-from-microsoft-azure-ad-to-sap-cloud-identity-services/ba-p/13546054 and specific hint on filtering users by a group in Identiy Provisionning Source system Properties, add aad.group.filter=displayName eq '<group_name>':

11. Establish trust between task sub account and IAS

Step 44
Go to BTP Cockpit->Security->Trust Configuration

Step 45
Select "Establish trust" and choose the IAS

Step 46
Select "Establish trust" and choose the IAS

Note: This creates an OIDC application in IAS for the subaccount

NB: Task Center/Service Now integration works only with OIDC trust between Task Center subaccount and IAS

Step 47
This would create an application in iAS

For more information, you can check: https://help.sap.com/docs/btp/sap-business-technology-platform/establish-trust-and-federation-between-uaa-and-identity-authentication

12. Setup the corporate identity provider and OIDC proxy in SAP Cloud Identity tenant

Step 48
Login as an administrator to your SAP Cloud Identity service administration console at
https://<IAStenant name>.accounts.ondemand.com/admin

Step 49
Go to Identity Providers > Corporate Identity Providers and click Create.
Enter a Display name(e.g. "Azure Active Directory") and click Save.

Step 50
Click on Identity Provider Type from the Trust settings of the new corporate identity provider.

Step 51
Select OpenID Connect Compliant from the list.
Click Save.

Step 52
Click on OpenID Connect Configuration from the Trust settings of the new corporate identity provider. 

Step 53
Enter your Azure AD tenant's OIDC Discovery URL (https://login.microsoftonline.com/<AAD tenant ID>/v2.0) Click Load.

The Issuer field gets populated from the loaded Azure AD tenant's OIDC metadata.

Step 54
Enter the SAPIASTenant's client ID in the Client ID field. In the Client Secret field, enter the value of theOIDCProxysecret copied in step 8.

Click Validate.

Step 55
Verify a successful validation of the OIDC configuration.

Click OK.

Step 56
Click + Add

Step 57
Copy and paste the full-qualified URI of the SAPIASTenant application's custom scope (api://<client id>/ias.access) copied in step 13 for the new scope.

Click Save.

Step 58
Click+ Add again and add the scope:
"email"
"openid"
"offline_access"

Click Save.

Step 59
Click Save.

Step 60
Go to Applications & Resources > Applications
Select the application from "Establish trust between Task subaccount and IAS" step – step 47

Click Attributes

Step 61
Navigate to Attributes and add

Name: "xsuaa-persist-corporate-idp-token"
Source: Expression
Value: true

Save

Step 62
Select "Conditional Authentication"
In the "Default Identity Provider", choose the Azure provider configured in steps 48-59, Click Save

13. Configure destinations for SAP in the BTP sub-account

SAP Task Center uses destinations to connect to Service Now task provider

 Client Specific configuration:

aadTokenEndpoint: Azure AD token endpoint athttps://login.microsoftonline.com/<AAD tenant ID>/oauth2/v2.0/token
iasTokenEndpoint: SAP Cloud Identity service tenant's token endpoint athttps://<IAStenant name>.accounts.ondemand.com/oauth2/token
iasTokenExchange: SAP Cloud Identity service's token exchange service endpoint athttps://<IAStenant name>.accounts.ondemand.com/oauth2/exchange/corporateidp

Step 63
Go back to the SAP BTP Cockpit and navigate to your CF subaccount.
Select Connectivity > Destinations from the navigation menu.
Click New Destination.

Step 64
Enter the following values for the first destination:
Refer to 6. TECHNICAL SERVICE FLOW

Click Save.

Step 65
Repeat steps 63 and 64 with following values for the second destination:

Refer to 10. CONFIGURE AZURE AS AN OAUTH OIDC PROVIDER ON THE SERVICENOW , step 21.

AuthnContextClassRef = urn:oasis:names:tc:SAML:2.0:ac:classes:X509
clientKey = token service password=client secret
Token service user = client id

Task Center documentation for Third Party destination setup: https://help.sap.com/docs/task-center/sap-task-center/connect-third-party-task-provider-and-sap-task-center

Click Save.

14. Test the scenario

Step 66
Use SAP Task Center Administration app to check the status of the configured connector destination, following: https://help.sap.com/docs/task-center/sap-task-center/working-with-task-center-administration-app

Step 67
Use SAP Task Center Web app, to validate that tasks from the new destination are seen by business users (for more information, see: https://help.sap.com/docs/task-center/sap-task-center/sap-task-center-web-app)

Nice patch SAP! Revisiting your SAP BTP security measures after AI Core vulnerability fix

2024-07-25T10:46:43.272000+02:00

Dear community,

SAP recently fixed a critical vulnerability in the SAP AI Core service that could have allowed attackers to access sensitive data in the multi-tenant environment. This issue, dubbed "SAPwned", was responsibly disclosed and publicly shared on July 18 after it was patched. You can read more about it here.

Bottom line: SAP shows its commitment to security and timely patching of its cloud services. But remember, SAP BTP - like any cloud platform - is based on a shared responsibility model. That means you need to do your part to protect your data and applications too:

Pick secure authentication means (no Basic AUTH is not one of them!),
Be conscious that every endpoint exposed by SAP BTP like Microsoft365 lives on the Internet by design,
Scope Cloud Foundry + Kyma app access, and user roles to the minimum rights needed,
When using the popular” OAuth2 client credentials grant” with service keys rotate your secrets (at best automatically regularly)! Have your pick from app based solution like this, PowerShell module and blog on automatic cert renewal.
Establish a continuous process to harden your SAP cloud workloads. It is not a one stop shop.

Ever heard about “MFA fatigue”? Plain Multi-Factor-Authentication is not good enough anymore today. Additionally, enforce Conditional Access to SAP BTP service through integration the SAP ID Service or the SAP Identity Authentication Service with the corporate identity provider of your choice. See here how to do it with Microsoft Entra ID.

Second line of defense: Automatic detections based on the SAP Audit Log Service

Most of the BTP based services in the Cloud Foundry environment provided by SAP automatically write to the SAP Audit Log Service. Each service lists the standardized events that are propagated.

SAP has a nice video on the general workings of the SAP Audit Log Service on BTP.

This is a good start, but how useful are log entries that record a compromise if they are overlooked and hidden among countless normal entries?

I use the Microsoft Sentinel for SAP BTP solution - which went into General Availability state this week - as an example for running automatic detections via built-in analytic rules. It connects to your subaccounts and global account ingesting all audit logs that are written to your registered Audit Log Management service instances. Polling interval is 10mins when deployed from the Azure Portal by default. Configure down to 1 min if needed using ARM API.

Architecture diagram of Sentinel solution for SAP BTP

It comes with out-of-the-box content. Check out the alert “Failed access attempts across multiple Business Application Studio accounts” for instance. Password spray attack anyone?

Screenshot of Sentinel for SAP BTP solution content with out-of-the-box detections and workbooks

Once I have onboarded my subaccount (I named it SAP-AI-Core-playground), I can go wild on the ingested log entries, apply the threat intel functions, and built analytic rules. Let's browse the entries via the Kusto query language. The standard table SAPBTPAuditLog_CL holds all audit log info for your registered SAP BTP subaccounts:

Screenshot of simple KQL for SAP BTP

The Message contains the JSON payload BTP provides for each message as well as the involved BTP service identifier.

Looking at audit messages is nice, but you may go one step further by applying automatic action like blocking the SAP BTP users.

Below Screenshot shows the part of the process triggered by the included playbook. The SAP security team gets notified with evidence of the compromise, offering an approval option to block the user from a Microsoft Teams channel flow. Find more info here. Below screenshot shows the adaptive card with a trigger from SAP Business Suite. The same is possible with triggers coming from BTP too.

Screenshot of sap btp user block approval request to SAP security team on Microsoft Teams

The AI Core Service audit log entries alone are not useful

Threat protection-wise correlation with other signals in your company is required, because a single SAP AI Core event like “Successful retrieval of object store secret” does not tell you anything. See below a Kusto query working off the AI Core audit log info ingested by the Sentinel for SAP BTP solution.

Note: SAP publishes the available events for all the Cloud Foundry based services here.

It identifies entries on my BTP subaccount related to AI Core activity and cross-references the IP address involved in the login and its country of origin. In my sample below I use the built-in function geo_info_from_ip_address() to learn if the BTP client remote address originated from Germany or not. Assumption here is that all my BTP developers are based there. Think about sanctioned countries lists etc.

//flag unexpected logins from countries other than Germany
let myBTPDevelopers = dynamic(['Germany']);
let login_messages = dynamic(['ClientAuthenticationSuccess','UserAuthenticationSuccess']);
SAPBTPAuditLog_CL 
| where SubaccountName == "SAP-AI-Core-playground"
| where Message has_any (login_messages)
| extend ip_ = tostring(Message.ip)
| extend country = geo_info_from_ip_address(ip_)['country']
| where country !in (myBTPDevelopers);

For a smoke test I teleported myself into the land of leprechauns🌈, steep cliffs, and mysterious celtic culture🍀 using an Azure VM. Marvel at the rule that identifies that mischieveous btp user!

Screenshot of found btp login from Ireland

The next sample uses the Threat Intelligence feature to verify if the BTP remote access can be traced back to a feed of known problematic IP indicators (e.g. a bot network). I maintained it on Sentinel on the Threat Management section using the IP known to BTP for my recent logins to the SAP AI Core service to trigger a result. In real life you would take the IPs from a threat intel feed of course. I don't have a bot net handy though😉.

Screenshot of Sentinel Threat Management experience

That makes it available to my Kusto query as below. See below the screenshot of the result:

Screenshot of Kusto query result filtered by problematic IPs

//flag unexpected logins from IP indicators from Sentinel
let ips = ThreatIntelligenceIndicator
| distinct NetworkIP = tostring(NetworkIP);
let login_messages = dynamic(['ClientAuthenticationSuccess','UserAuthenticationSuccess']);
SAPBTPAuditLog_CL
| where SubaccountName == "SAP-AI-Core-playground"
| where Message contains "aicore" and Message has_any (login_messages)
| extend ip_ = trim(" ", replace(@"\s", "", replace(@"\r|\n|\t", "", tostring(Message.ip))))
| join kind=inner (
    ips
    | extend NetworkIP_ = trim(" ", replace(@"\s", "", replace(@"\r|\n|\t", "", tostring(NetworkIP))))
) on $left.ip_ == $right.NetworkIP_;

A natural next evolution of the detection would be to extend it to the "impossible travel" scenario.

These queries are simple to set up and are good to go to serve as new analytics rule on the solution, don’t you think?

Let me know what other scenarios you would like to see 😊

Thoughts on production readiness

SAP’s Audit Log Service is widely adopted across the SAP BTP services and foundational to the platform.

Sentinel for SAP BTP recently went into “General Availability” state, making it good to use for anyone who doesn’t like previews 😎

To create meaningful detections based on the SAP BTP audit log at minimum other sources, such as the Authorization and Trust Management service (XSUAA) must be considered. Enriching your threat signals with indicators from the rest of your IT landscape gets you from "SAP-security-acolyte"🧑🏻‍🏫 to master of disaster🥷🏼.

The built-in Sentinel for SAP playbooks use SAP BTP public APIs for automatic remediation. See the user API documentation for disabling users here.

Final words

Constantly staying ahead of attackers all the time is impossible. However, putting up a fight so they move on without doing more serious damage or at least being automatically informed about the incident puts you back in the driver’s seat.

The Sentinel for SAP BTP solution enables you to bring the SAP BTP audit log information for cross-correlation with your wider IT landscape to the Microsoft SIEM solution Sentinel. Furthermore, it powers automatic remediations like user block, password reset, and more.

For true confidence in drastic actions like blocking users, you require signals from as many sources as possible. Think beyond the SAP boundary and towards your complete IT landscape: Devices, endpoints, and suspicious logins etc. All of those touchpoints leave a trail of your attacker long before they reach SAP BTP, because of the prior phishing attempts or lateral movement etc. Have a look at Defender XDR for further info.

What detections are you running for your BTP landscape? Let the community know so we can learn from each other’s security practices.

Cheers

Martin

to be posting

2024-07-25T13:54:39.738000+02:00