SAP Community - Security

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

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

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

Introduction

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

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

Background

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

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

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

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

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

Scope of the ISAE3000 Assurance Report

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

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

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

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

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

Requesting a Copy of the ISAE3000 Assurance Report

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

For requesting the report, kindly follow these steps:

Go to SAP Trust Center
Select Compliance

Select Find Compliance Documents

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

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

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

Conclusion

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

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

For more updates you can follow me via LinkedIn.

INFLUENCE THE DEVELOPMENT OF SAP ENTERPRISE THREAT DETECTION, CLOUD EDITION

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

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

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

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

The rationale and advantages of a customer influence page include:

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

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

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

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

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

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

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

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

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

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

Threat Actors targeting SAP Applications

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

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

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

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

So as SAP Customers, what should we do?

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

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

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

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

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

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

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

Responsibilities in General

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

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

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

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

Auditing cloud applications

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

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

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

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

Customer Audits

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

Different Cloud Deployment Models

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

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

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

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

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

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

The differences in SAP S/4HANA deployment models

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

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

SAP Secure Operations Map

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

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

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

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

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

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

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

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

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

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

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

The application

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

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

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

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

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

Conclusion: Lots and less to think about

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

Streamlining User Provisioning from IBM Verify to SAP Cloud Identity Services

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

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

The Challenge of User Provisioning

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

Transitioning from IBM Verify to SAP Cloud Identity Services

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

How does it work?

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

Prerequisites

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

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

Log into IBM Security Verify as an administrator

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

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

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

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

You have to enable the cloud identity services application.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

More information:

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

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

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

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

What are we discussing here?

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

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

How are we going to achieve it?

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

What is USR21?

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

What is ADR6?

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

Procedure to Extract Email Address from SAP Tables

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

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

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

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

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

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

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

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

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

Handling profile parameter values in SAP NetWeaver and SAP HANA

2024-05-13T15:15:53.323000+02:00

Profile parameters accompany the SAP Basis administrators their entire lives. Still, in many SAP systems one can find sub-optimal handling of those and when it comes to monitoring or compliance checking one may be curious how to determine the currently effective values. This may be from a special interest if one considers to implement a tool for compliance checking.

In this blogpost I like to give a brief overview about profile parameters, maybe some handling tips.

In another blogpost I give an overview about how the effective profile parameter values can be determined.

Effective Parameters

At first we must know that many profile parameters have a so called „kernel default value“. This value is compiled into the kernel and will take effect if it is not overwritten by other means - we will come to that in a few.

We can display the kernel default values of all parameters recognized by the actual SAP kernel for example by running the command sappfpar all on OS-level as user <sid>adm.

Please note: Looking at the output we may find some profile parameters which have no kernel default value and some parameters are entirely unknown to the kernel and therefore are not listed in the output at all. Values for these profile parameters must then be set explicitly in a profile file. An example would be the parameters ccl/* to setup the CommonCryptoLib.

The kernel default values might change with newer releases or patch levels of the SAP kernel. New sub-parameters might be added to existing profile parameters. Furthermore, completely new parameters may be added and in rare cases parameters get removed.

Please note: SAP started to provide a list of what has been changed for profile parameters. We can find this in the What's New Viewer in the section ABAP Server Infrastructure -> Parameter Changes. For example, here.

To make profile parameter values configurable and persistent they have to be stored in the so-called profile files. At system startup the profile parameters’ values are read from those profile files residing on the filesystem. This happens in the following order:

#	Identifier	Location
1.	kernel default value	compiled into the kernel
2.	default profile	for SAP NW: /sapmnt/$SAPSYSTEMNAME/profiles/DEFAULT.PFL for SAP HANA: /hana/shared/$SAPSYSTEMNAME/profile/DEFAULT.PFL for SAP Host Agent: n/a
3.	Instance profile	for SAP NW: /sapmnt/$SAPSYSTEMNAME/profiles/$SAPSYSTEMNAME_<instance_name>_<saplocalhost> for SAP HANA: /hana/shared/$SAPSYSTEMNAME/profile/$SAPSYSTEMNAME_<instance_name>_<saplocalhost> for SAP Host Agent: /usr/sap/hostctrl/exe/host_profile

With this, we must keep in mind: A value from the instance profile might oversteer a value from the DEFAULT.PFL. In some cases, this may be used by intent.

Determine the correct profile for a parameter and use variables to define its value

As a rule of thumb, instance profiles (file name <SID>_<INSTANCE>_<HOST>) should contain only parameters which are specific for the particular instance.
Instance specific parameters may also be shifted into the DEFAULT.PFL if there is a variable available which can be used to make values instance specific while defining them in the DEFAULT.PFL.

To make this concept more clear, I like to give an example for that based on the profile parameter icm/HTTP/logging_<xx>:

We should prefer to set the following in the default profile
icm/HTTP/logging_0 = PREFIX=/,LOGFILE=$(DIR_LOGGING)$(DIR_SEP)↵
icm_http_server_$(SAPSYSTEMNAME)_$(INSTANCE_NAME)_$(SAPLOCALHOST)-%y-%m-%d.log
over setting the following in the instance profile
icm/HTTP/logging_0 = PREFIX=/,LOGFILE=/usr/sap/NPL/D00/log/↵
icm_http_server_NPL_D00_vhcalnplci-%y-%m-%d.log

In this example, we've made the value independent from the SID, Instance Name, hostname and we also made the value independent from the operating system by specifying the path by the variable $(DIR_LOGGING) and the delimiter using $(DIR_SEP). So, no matter how many instances our system has, even if heterogenous, we can rely on the desired value will take effect on each instance.

Excursus:
Having a closer look at the kernel default value of the profile parameter DIR_LOGGING we will see that it is specified as $(DIR_INSTANCE)$(DIR_SEP)log. And DIR_INSTANCE is specified as $(DIR_SEP)usr$(DIR_SEP)sap$(DIR_SEP)$(SAPSYSTEMNAME)$(DIR_SEP)$(INSTANCE_NAME). For DIR_SEP the kernel default value is hard coded in the OS-specific SAP Kernel, for Linux it is "/".
Knowing this, we can note: even nested usage of variables is possible.

Another example would be the kernel default profile parameters ES/SHM_SEG_SIZE and ES/SHM_MAX_PRIV_SEGS. Both make use of variables. They are so called formula parameters. Their values are determined by using math functions:
ES/SHM_SEG_SIZE = ($(em/blocksize_KB)/1024 * (ceil(max($(ztta/max_memreq_MB) *2, $(abap/shared_objects_size_MB) + $(rsdb/tbi_buffer_area_MB) + 4*($(em/blocksize_KB)/1024)) / ($(em/blocksize_KB)/1024))))

and show that calculated values can be used as variables for further calculations:

ES/SHM_MAX_PRIV_SEGS = (ceil(max($(ztta/roll_extension_dia), $(ztta/roll_extension_nondia)) / (1024*1024 * $(ES/SHM_SEG_SIZE))) + 1)

Precisely, there are only very few profile parameters which must be set in the instance profile.

Please note: The only deviation I came across are the rdisp/wp_no_* profile parameters which need to be set explicitly in the instance profile to be recognized correctly by the "Operation Modes and Instances" editor of transaction RZ04. A warning will be displayed if these profile parameters are not present in the instance profile. Even though, the values for these profile parameters would be correctly determined and used if they would be defined in the default profile only.

Some parameters are flagged as system-wide when being displayed in transaction RZ11 and therefore should never be set in any instance profile.

Maintaining profile parameter values

For maintaining profile parameter values, we have basically two possibilities.

1. Maintain the profile files on the OS-level using your preferred text editor.

Please note: If you maintain the profiles on OS-level, you should import profiles before displaying them in RZ10 to avoid inconsistencies.

2. Logon to the system and use transaction RZ10.

Please note: In RZ10 the instance profile of the ASCS instance (/usr/sap/<SAPSID>/SYS/profile/<SAPSID>_ASCS<nn>_<hostname>) could be included after implementing SAP Note 2789094.

Profile parameter values become effective during the system startup. Some time this is also referred as 'they become "activated"'.

Change profile parameter values at runtime (Dynamic Parameters)

For some profile parameters it is possible to change their value at runtime. These parameters are known as "Dynamic Parameters". Changes to such dynamic parameters during runtime (aka. "changes in productive operation") are withdrawn after a system restart.

We can change profile parameters via web methods offered by the SAP Instance Agent (aka SAP Start Service):
sapcontrol -nr <Inst-No> -function [SetProcessParameter|SetProcessParameter2]

Within AS ABAP, changes during runtime can be performed using transaction RZ11 or function module TH_CHANGE_PARAMETER or SPFL_PARAMETER_CHANGE_VALUE.

For the ICM, vector parameters like icm/HTTP/logging_<xx> can be changed using the Function module ICM_SET_VECTOR_PARM. Some components like the ICM will recognize dynamic parameter changes and will perform a soft-restart, others will just use the new value for their next task execution.

Please note: There are a few profile parameters which allow a change at runtime depending on their current value. Which means, we can change the value from 'a' to 'b' without a restart, but changing back from 'b' to 'a' would need a restart. This is for security reasons.

Transaction RZ11 provides a change history for dynamic changes performed since the last restart of the system. The link to the change history can be found below the "Current Value of Parameter"-table indicated by "Origin of Current Value: Dynamic Switch ( Change History )".

As this link is only displayed if there have been changes since the last restart of the system, Frank Buchholz provided the report ZRSPFPAR_DYNAMIC_CD which can be found at GitHub https://github.com/SAP-samples/security-services-tools to make them visible for all dynamic changes. Values different to the effective value are displayed in yellow, values identical to the effective value are displayed in green.

Please note: As of SAP note 2201397 only the last 10 dynamic changes are logged. If you want to see all changes you have to search the syslog for the IDs Q19, Q1A.

Security by Default vs Security by Design # 2

2024-05-19T09:56:24.460000+02:00

In my previous article, I’ve detailed about the nuances of securing SAP systems and the debate surrounding Security by default and Security by design. Those who missed it, can have a look at the blog post using this link.

https://community.sap.com/t5/financial-management-blogs-by-members/security-by-default-vs-security-by-design/ba-p/13593897

Now, let's further explore the imperative of adopting a “Security by design” approach within SAP environments. As mentioned, with cyber threats becoming increasingly sophisticated and pervasive, organizations must embed security considerations into every facet of SAP solutions is more critical than ever.

The Evolution of Security by Design

Wait, I know you have in your mind! If Security by Design is important, why hasn't SAP included these features as standard?

The concept of "Security by Design" has become increasingly vital to address various requirements to arrest Cyberattacks. “Security by Design” approach emphasizes integrating additional security measures in various levels of software systems and just not in the foundation. However, despite its recognized importance, some may wonder why SAP, hasn't made Security by Design a standard feature in its products?

The answer is simple!

SAP’s focus is ERP and automating and integrating various business functions, but not a core Cybersecurity function. However, SAP is bringing various solutions now starting from SAP GRC solution suite, till implementing of various frameworks such as NIST. Here is how SAP is bringing it’s various solutions to meet the NIST Cybersecurity framework:

Source: SAP

Before we understand how these solutions can be used, here are the few steps that you should implement. I am not covering this from a 7 layer perspective and as Security as the primary focus considering the “Security by Design” approach. The broad layers to be focused are:

Environment
System
Application
Processes, and
Organization

Security by design emphasizes proactive risk mitigation, empowering organizations to identify and address security vulnerabilities at the earliest stages. By conducting comprehensive risk assessments and threat modeling exercises, organizations can anticipate potential security threats and implement safeguards accordingly.

Additionally, relying solely on static security measures is insufficient in combating evolving cyber threats. Security by design advocates for the implementation of adaptive defense mechanisms that can dynamically respond to emerging threats in real-time. This includes leveraging machine learning (ML) algorithms and artificial intelligence (AI) to detect anomalous behavior and pre-emptively mitigate security risks.

In conclusion, the adoption of a security by design approach is indispensable for securing SAP environments in an increasingly volatile threat landscape. By integrating security considerations into every stage of the SAP development lifecycle, organizations can mitigate risks, enhance resilience, and safeguard critical assets from cyber threats. I will provide more detailed insights into each of these levels in my next article. Stay tuned!

Unlocking the Power of RSUSR_LOCK_USERS Report in SAP

2024-05-20T16:11:52.741000+02:00

Are you finding it challenging to use EWZ5 for locking and unlocking users during upgrade activities? Have you discovered that this transaction code is now obsolete and are you relying on a custom program? If so, consider using the ABAP program RSUSR_LOCK_USERS.

This program simplifies the user locking and unlocking process, making it an invaluable tool for managing user accounts efficiently during system upgrades.

Understanding RSUSR_LOCK_USERS

RSUSR_LOCK_USERS is a simple yet effective program that is built on top of RSUSR200 program. Here is the list of options available in the program screen:

As highlighted in the picture, the RSUSR_LOCK_USERS report offers the following sections:

Section	What it offers?
User Selection	This section offers the following: User – Selection of specific users. Group for Authorization – Uses SU01 user group assignments and picks the users based on the group assignment. Security Policies – Uses the Security Policy assigned to the user in SU01. Days Since Last Logon – To specify the no.of days since last login (for eg: If you wish to lock the users who haven’t logged-in to the system in the last 90 days, enter the value as 90). Days Since Password Change – To select users based on last password change.
Selection by Validity of users	Selection by Validity of users can be filtered by today's validity or by a specific period. Today (current date) – This option will specifically check for valid and invalid users of current date. Users Valid Today – Consider the valid users of current date Users Invalid Today – Consider the Invalid users of current date Validity Period – This option will specifically check for valid and invalid users over a specified period of time. Users Valid <From> and <To> - Consider the valid users within the time period specified in the input. Users Not valid <From> and <To> - Consider the Invalid users within the time period specified in the input.
Selection by Locks	This option facilitates filtering users based on their lock status. Below are the lock criteria that can be considered. Selecting one of these options is mandatory (Radio button selection). Differentiation of Locks All users with Administrator or Password Locks Only Users without Locks *Differentiation of Locks* User Locks (Administrator) – When the value "Set" is selected, it will include the list of users who have been locked by the administrator, with lock statuses of 32 and 64. When the value " Not Set" is selected, it will exclude the list of users who have been locked by the administrator, with lock statuses of 32 and 64 Password Lock (Incorrect Logon) – When the value "Set" is selected, it will include the list of users who have been locked due to incorrect logons with the status of 128 while when the value “Not Set” is selected, it will exclude the list of users who have been locked due to incorrect logons with the status of 128 *All users with Administrator or Password Locks –* It will include all users who meet the condition of being locked by the administrator (with lock status 32 & 64) or having password locks (with lock status 128). *Only Users without Locks -* It includes users without any lock status (Active users)
Selection by Login attempts	This section sorts users based on their login attempts to the SAP system. By default, all options are selected, and you can deselect a box to exclude. Alternatively, all boxes can be unchecked if you do not wish to use this option. Users with incorrect Logon Attempts – Considers users who have made incorrect logon attempts. Users with no Incorrect Logon Attempts – Considers users who have not made any incorrect logon attempts. User Without Logon Date – Considers the users without any logon date in SU01
Selection by User Type	Selection by User Type filters users based on the user type defined in SU01. For example, you can lock only dialog users based on conditions specified within this program, such as users who have not logged into the system for a specific period of time. Below are the user types available under this criteria: Dialog Users Communication Users System Users Service Users Reference Users NOTE: By default, all options are selected, and you can deselect a box to exclude. Alternatively, all boxes can be unchecked if you do not wish to use this option.
Selection by status of password	This section will be considered the users based on the status of the user password. ·Users with Production Password – Productive user Users with Initial Password – Users who have never logged into the SAP system after the initial password was set by the admin. Users with Deactivated Password – Users who password is deactivated As selection type “Selection by Login attempts and Selection by User Type”, by default, all options are selected here as well, and you can deselect a box to exclude.
Activity selection	Once all the selection criteria are defined according to your requirements, you can proceed to the Activity selection option to specify your actions. Based on the conditions specified above, the result will now be executable. Below are the actions that can be taken when you execute the program. Test Selection – Test Selection presents the list of users on the output screen according to the criteria defined before any of the activities listed below are executed. Lock Users (Local Lock) – To Lock the user locally Unlock Users (Local Lock) – To unlock the user locally Set the End of the Validity Period to Today (Only for Valid Users) – Validity of the user will be ended with today’s date Set the End of the Validity Period to Yesterday (Only for Valid Users) – validity of the user will be ended with the yesterday’s date

As mentioned, RSUSR_LOCK_USERS aids in compliance and audit processes by providing a clear record of user account status and actions taken. This ensures that the organization can demonstrate adherence to security policies and regulations.

How to Use RSUSR_LOCK_USERS?

Execute transaction code SA38 or SE38.
Enter “RSUSR_LOCK_USERS” in the program field and execute the report.
Complete the required selections such as specific users, lock/unlock conditions, and date ranges etc.,
Run the program to generate a list of users.

Consider the following condition for ending the validity of users as a reference. I have selected dialog users regardless of their password status—whether it's production, initial, or deactivated—and those who are already locked by the admin or due to password lock. Additionally, I have chosen users without logon data under "Selection by Logon Attempts." Once users meeting the defined criteria are identified, their ID validity should be set to end with yesterday’s date.

After executing the program, the output will display the User IDs for which changes were made.

Result: According to the given criteria, user validity is ended with yesterday's date. The program was executed on 20.05.2024, so the user validity is set to end on 19.05.2024.

Additionally, the program can be scheduled to run at regular intervals, ensuring that administrators are always aware of any locked user accounts. Automation can help in maintaining continuous oversight without manual intervention.

Steps to schedule the job in the background:

To automate the locking, unlocking, and validity ending of users without manual intervention, you can schedule this job to run in the background. This enables the program to execute automatically at specified intervals, ensuring users are locked or unlocked according to predefined criteria. It's recommended to thoroughly test the program in a non-production environment before scheduling it in a production system to ensure proper functionality and minimize potential disruptions. Follow the below steps to schedule the job in the background:

Execute transaction SE38 and input the program RSUSR_LOCK_USERS, then proceed to execute it.
Define the criteria for locking/unlocking or ending the validity of the user.
Click "Program" to schedule the job in the background or press F9

4. Specify the frequency at which the job should run and click Save.

When you have multiple criteria to schedule in the background, specify your criteria and press Ctrl+S to save as a variant as shown below:

After saving the variants, the job can now be scheduled in the background via transaction code SM36.

Conclusion

The RSUSR_LOCK_USERS program is an indispensable tool for SAP administrators, providing critical insights and control over user account management. By effectively utilizing this program, organizations can enhance their security posture, ensure compliance with regulations, and maintain smooth operational workflows. Regular use and prompt action on the findings of the RSUSR_LOCK_USERS report will help in minimizing user access issues and reinforcing overall system security.

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

SAPクラウドサービスにおける個人情報保護法の考え方

2024-06-19T17:08:57.395000+02:00

クラウドサービスの利用を考える企業から個人情報の取り扱い、特に個人データの第三者提供に該当有無について、尋ねられることがしばしばあります。この個人情報の取り扱いについて企業が悩む背景には、クラウドサービス特有の環境があると考えています。クラウドサービスはオンプレミスと異なりクラウドサービスプロバイダーが管理・運用する環境に企業の情報やデータをアップロードし処理及び保存等を行います。そのため、クラウドサービスプロバイダーが主体となり個人情報の取り扱いをしていると考えられる傾向があります。その結果、個人情報保護法の解釈及び適用においてクラウドサービスを利用する企業とクラウドサービスプロバイダーとの間で議論になることがあります。

本ブログでは、SAPクラウドサービスの利用を前提に議論となるクラウドサービスの個人情報の取り扱いについて説明をしたいと思います。

個人情報と個人データ

本ブログで個人情報の取り扱いを説明する前に整理しておきたい単語があります。それは、個人情報と個人データです。この違いについて個人情報保護委員会のFAQ 2-3 によると、個人情報は生存する個人に関する情報です。また、個人情報を容易に検索することができるように体系的にまとめ、データベース化されたものが個人データです。個人データは個人情報の検索や参照が容易になることから個人情報保護法において遵守すべき事項が多くなります。

クラウドサービスは基本的に企業からクラウドサービスにアップロードされた個人情報を個人データ化し、その個人データを企業の要件に従って処理を行うためのサービスとなります。従って、クラウドサービスにおける個人情報の取り扱いを考える上で重要となるのは個人データの取り扱いになります。ここでは、個人データの取り扱いにおいて個人情報保護法の中でクラウドサービスプロバイダーはどのような位置付けになるのかを考えて行きます。また個人情報保護法において個人データの取り扱いを知ることで、個人情報保護法の解釈及び適用がなぜ議論されるのかが見えてくると考えています。

個人情報保護法とクラウドサービス

クラウドサービスで個人情報を取り扱う場合、個人情報保護法の解釈及び適用について議論として挙げられるのが、法第27条に書かれている個人データを第三者に提供してはならないという箇所です。

法第27条：個人情報取扱事業者は、次に掲げる場合を除くほか、あらかじめ本人の同意を得ないで、個人データを第三者に提供してはならない。

この第三者がクラウドサービスプロバイダーが該当するのか否かですが、この第三者に該当判断を行うに辺り、参考になるのが法第27条5項及び第27条第5項第1号となります。

法第27条5項：次に掲げる場合において、当該個人データの提供を受ける者は、前各項の規定の適用については、第三者に該当しないものとする。

第27条第5項第1号：個人情報取扱事業者が利用目的の達成に必要な範囲内において個人データの取扱いの全部又は一部を委託することに伴って当該個人データが提供される場合

法第27条5項及び第27条第5項第1号によると、クラウドサービスを利用する企業からクラウドサービスプロバイダーは個人データの取り扱いを委託されているかどうかによって第三者の該当を判断することできます。では、委託の意味ですが、それは「個人情報の保護に関する法律についてのガイドライン（通則編）」の3-4-4 委託先の監督（法第25条関係）の注釈に答えがあります。注釈には以下のように書かれています。

通則編 3-4-4：（※1）「個人データの取扱いの委託」とは、契約の形態・種類を問わず、個人情報取扱事業者が他の者に個人データの取扱いを行わせることをいう。具体的には、個人データの入力（本人からの取得を含む。）、編集、分析、出力等の処理を行うことを委託すること等が想定される。

この注釈によると、委託に該当するには個人データの入力（本人からの取得を含む。）、編集、分析、出力等の処理を行うこととされています。では、クラウドサービスにおける通則編 3-4-4に示される4つの処理について考えたいと思います。

まず初めに個人データの入力ですが、基本的に個人データの取得はクラウドサービスを利用する企業が行うため、クラウドサービスプロバイダーは一切関わらることがありません。そのため、入力において委託は該当しません。

続いてですが、編集、分析、及び出力の3つを同時に考えたいと思います。編集、分析、及び出力においてクラウドサービスはクラウドサービスを利用する企業が望む形に入力された個人データを編集、分析、及び出力するための支援を行っているにすぎず、主体性を持って行うことはありません。そのため、編集、分析、及び出力においてクラウドサービスプロバイダーが主体となり実施していないので、委託に該当しないと言えます。

通則編 3-4-4が示す個人データの取扱いの委託にクラウドサービスプロバイダーが該当しないとするならば、法第27条に書かれている第三者の定義にクラウドサービスプロバイダーは該当しないため、クラウドサービスプロバイダーへ個人データの提供は非該当と言えます。

SAPクラウドサービス提供において上記を実施しないので、個人データの取扱い委託に該当しないとSAPは考えています。

尚、この委託の定義が個人情報保護法の解釈及び適用がなぜ議論の鍵となるため、実際にクラウドサービスの利用を検討される際にはこの委託についてしっかりと確認を行うことをお勧めします。

クラウドサービスプロバイダーが個人データの提供に該当しないとはいえ、クラウドサービスプロバイダーは個人データを自身が運営・管理する環境の中で行っているため、個人データを保護する責任はあります。それは個人情報保護委員会のFAQ7-53でも触れられています。

FAQ 7-53（一部抜粋）：当該クラウドサービス提供事業者が、当該個人データを取り扱わないこととなっている場合とは、契約条項によって当該外部事業者がサーバに保存された個人データを取り扱わない旨が定められており、適切にアクセス制御を行っている場合等が考えられます。

FAQ 7-53では、個人情報の取扱いについてより明確なガイドラインを提供しています。SAPは契約書に顧客の指示に従ってのみ顧客データの処理を実施すると記載しています。このことからも、SAPクラウドサービス提供において、個人データの取扱い委託に該当しないと考えています。

クラウドサービスプロバイダーが個人データの取り扱いの委託に該当しないとするならば、クラウドサービスプロバイダーは適切なアクセス制御を実施しなければならいとされています。つまりクラウドサービス上に保存された個人データに対して物理的及び技術的にアクセスできない環境を構築し、またそれらについて契約条項で示す必要があります。では実際にどのような対策が講じられているか説明をします。

個人情報を守るためのアクセス制御

個人データはもっとも機微な情報の一つであると言えます。そのため、個人データを預かるクラウドサービスプロバイダーはしっかりとしたアクセス制御を講じる必要があります。ここからはSAPが実際に実施しているアクセス制御の一部を基に個人データへの適切なアクセス制御を紹介していきます。

詳細は以下の契約文書（英語）を参照してください。

https://assets.cdn.sap.com/agreements/data-processing-agreements/tom/technical-and-organizational-measures-toms---sap-cloud-services-english-v8-2021.pdf

・システムアクセスコントロール

・個人情報が保存及び処理されるシステムへのアクセスを厳しく制限するため、アクセスを許可するユーザは複数の権限レベルを持つ者に限っており、またアクセス許可を付与する場合には厳正な審査を行った後にアクセス権を付与しています。

・アクセスに用いるパスワードは他人との共有を禁止及び適切な管理（定期的なパスワード変更、要件に従った複雑なパスワードなど）を定めたポリシを策定し、また適切な管理が実施できるようにシステムによるパスワード管理を行っています。

・ファイヤウォールを用いてSAPのネットワークとシステムのネットワークを分断し、またパブリックネットワークから保護も行い、不正なアクセス対策を講じています。

・システムの脆弱性対策として、定期的かつ適切にセキュリティパッチの適用を実行しています。

・データアクセスコントロール

・個人情報へのアクセスはシステムを使用する権利（クラウドサービスを利用する企業）を有するものに制限しております。

・尚、SAPはクラウドサービスを利用する企業から求められた場合（例えばサポート等）に限り、システムを使用する権利を有する企業の許可を得た上で、適切な社内プロセスに従いアクセス許可をSAPの従業員に与えることがあります。

・システムのサーバーはセキュアなサーバールーム内で運用し、保護するセキュリティ対策は定期的に確認をしています。

・データアクセスにおいて不備などがないかを確認するため、定期的に脆弱性診断及びペネトレーションテストを実施しています。

・データ入力コントロール

・個人情報が SAP のシステムから入力、修正、又は削除されたかどうか、及び誰によって削除されたかを遡及的に検証し、立証することができるように対策を講じています。

・SAPはクラウドサービスを利用する企業から求めに応じてシステムを使用する権利を有する企業の許可を得た上でアクセスを行う場合、クラウドサービス内において技術的に可能な範囲においてクラウドサービス内での作業を記録するためにログシステムを実装しています。

・データ分離の管理

・SAP はデプロイされたソフトウェアの技術的機能を使用して、論理的なデータ分離を実現し、クラウドサービスを利用する企業が自身のデータのみにアクセスできるようにしています。

上記より、SAPはクラウドサービス提供においては個人情報の取扱いはせず、適切な安全管理措置を実施しています。

最後に、クラウドサービスにおける個人情報の取り扱いはクラウドサービスの機能や契約形態により異なったり、法解釈によって異なる場合があります。従って利用を検討されている企業での検討もお願いします。また、個人情報保護法は定期的に改定が実施されています。従って、導入時や定期的に貴社の法務担当と確認されることをお勧めいたします。

Sap Authorization Audit Readiness & Critical Access Monitoring!!!

2024-06-26T07:12:42.494000+02:00

As an SAP Authorization consultant, year on year we go through Internal/External Audit trials and provide evidence/clarifications for the samples requested.
We need to justify if there a slippage in Process/Access assignments and leading to Audit Deficiencies failed to provide evidence.
Auditors will leave no chance to find a process gap like an eagle catching a fish which is just above the river 🙂

To avoid Audit deficiencies, we need to have a detailed SOP (Standard Operating Process), religiously follow the process and document exceptions, if any.
The most important aspect is to monitor Critical authorization assignments on monthly(suggested) or quarterly to assess unwanted assignments and remediate even before noticed by Audit team.

I have outlined most of the Critical Authorization monitoring controls as follows

1. Security Audit Parameters

Below table provides generic Audit Parameters to be configured in Production systems, which are most important with regards to Audit controls. Below values specified are with respect to SAP best practices and may differ from individual organizations as well.

Password Parameters	Value
login/min_password_lng	12
login/min_password_digits	1
login/min_password_lowercase	1
login/min_password_uppercase	1
login/min_password_specials	1
login/password_history_size	4
Login and Session
login/failed_user_auto_unlock	1
login/fails_to_session_end	3
login/fails_to_user_lock	6
login/no_automatic_user_sapstar	1
rdisp/gui_auto_logout	1800
auth/object_disabling_active	N

2. SAP Standard User Password and Active Status

Sap Standard users such as SAP*, DDIC, TMSADM, SAPCPIC etc should have their initial password changed and keep locked these users in clients such as 000,001,066 & Prod client and in some cases TMSADM and DDIC will be kept unlocked in master clients.

To validate Execute Tcode RSUSR003.

3. Critical Standard Profiles (SAP_ALL and SAP_NEW)

SAP standard critical authorization profiles SAP_ALL or SAP_NEW must not be assigned
to any users in any of the clients.
To check Go to SUIM-->Users by Complex Selection Criteria-->Roles/Profiles-->Profile Name SAP_ALL and SAP_NEW.

4. Standard SAP Roles Assignment

Any users in Production client must not be assigned with SAP standard roles i.e Roles starting with SAP* or /*. To check go to SUIM-->Users by Complex Selection Criteria-->Roles/Profile--> SAP* or /*.

5. Access to Create User Master

Access to create User master in Production should be restricted to Authorization team, since they need to create Service/System users. Dialog user creation should be via GRC system.
To Check SUIM >User by Complex Selection Criteria >S_USER_GRP ACTVT = 01

6. Access to Change User Master

This access is restricted to Authorization team and any other user should not be assigned with.

SUIM report >User by Complex Selection Criteria >S_USER_GRP ACTVT = 02 or 06

7. Access to Unlock Users or Reset Password

In ideal scenario, IT/Business user login to Production system via SSO (Single Sign On). There are exceptions for password login such as IT Admin Users (Security & Basis) and few Business users, who need to connect to third party tools (example RF Gun) via Production user credentials. All the exceptions should be documented in SOP.

SUIM report > User by Complex Selection Criteria > S_USER_GRP ACTVT = 05

8. Access to Debug with Change

Debug change access must be restricted from any Dialog users in Production and it should be part of an FF user only.
To check SUIM report > User by Complex Selection Criteria > S_DEVELOP ACTVT = 02
and OBJTYPE = DEBUG

9. Access to Import Transports

Only Basis/Release team should have access to import access in Production system.
SUIM>User by Complex Selection Criteria >S_CTS_ADM > Value= IMPA or IMPS
SUIM report > User by Complex Selection Criteria > S_TRANSPRT ACTVT = 60

10. Execute Access for All Programs

No Users in Production should be assigned with all Program execute access.

SUIM >User by Complex Selection Criteria >S_PROGRAM P_ACTION = SUBMIT & P_GROUP = #*

11. Authorization Objects Added Manually or Changed in Roles

All authorization objects in the roles should be in Standard or Maintained status. Any exceptions should be documented. As per SAP best practice no objects should be added manually and there will be adverse effect during upgrades, since tcodes will fail which are dependent on manually added objects, but not linked via SU24.

12. Custom Tcodes Without Authorization Object Linkage in SU24

Custom Tcode must be associated with authorizations objects maintained in SU24.
To check, extract all custom tcodes from SE16-->TSTC-->Z*
Next copy tcodes from TSTC into table USOBT_C to check tcodes with SU24 object mappings and if tcodes not available in the report, then such custom tcodes must be added with suitable auth object into SU24.

13. Administrator Access for All Batch Jobs

Batch admin access with Administrator i.e Y access should be restricted to Basis team.
SUIM report > User by Complex Selection Criteria > S_BTCH_ADM BTCADMIN = Y

14. Access to Delete Batch Jobs

SUIM report >User by Complex Selection Criteria >S_BTCH_JOB JOBACTION = DELE

15. Access to Delete Logs or Jobs in Batch Input Processing

SUIM report > User by Complex Selection Criteria > S_BDC_MONI BDCAKTI = REOG or DELE

16. Access to All Batch Input Processing Sessions

SUIM report > User by Complex Selection Criteria > S_BDC_MONI BDCGROUPID = #*

17. RFC Administration Access

This acccess should be restricted to either basis team or Batch Monitroing teams.

SUIM report > User by Complex Selection Criteria > S_TCODE = SM59 and S_ADMI_FCD = NADM

18. Execute Access for All RFCs

This access should not be assigned to any Dialog users in Production system. For Batch job users also assign only required RFC authorization based on trace results, rather assigning full access.

SUIM report > User by Complex Selection Criteria > S_RFC = #* (or S_RFC = "*")

19. Change Access for All Tables

SUIM report >User by Complex Selection Criteria >S_TABU_DIS ACTVT = 02 and DICBERCLS = #*
SUIM report >User by Complex Selection Criteria >S_TABU_NAM ACTVT = 02 and TABLE = #*

20. Display Access for All Tables

You may be wondering why display access is critical, this is because a business user with display access on all tables can view Business critical information and leading to Business loss/audit deficiency.

SUIM report >User by Complex Selection Criteria >S_TABU_DIS ACTVT = 03 and DICBERCLS = #*

SUIM report >User by Complex Selection Criteria > S_TABU_NAM ACTVT = 03 and TABLE = #*

21. Access to Modify Client Settings

SUIM report User by Complex Selection Criteria >S_TABU_DIS ACTVT = 02 and DICBERCLS = SS
SUIM report >User by Complex Selection Criteria >S_TABU_NAM ACTVT = 02 and TABLE = T000

Note: Auth Group SS contains Security relevant tables and hence should be assigned to IT team only.

22. Access to Tables Not mapped to Authorization Groups

Tables i.e Both Standard and Custom, that are not mapped to specific authorization groups, will be automatically assigned to &NC& group. We need to make sure no users should have change access to group &NC& in Production.

23. Access to Maintain Cross-Clients Tables

SUIM report > User by Complex Selection Criteria > S_TABU_CLI CLIIDMAINT = X

Conclusion:

Frequent monitoring of above critical access assignments will help to be prepared for Audit at any day and IT HPA (High Privilege Access) review as well, to make sure only relevant IT users assigned with privileged access.

Regards

Shivkumar

Update on the SAP Identity Management migration to Microsoft Entra

2024-06-26T18:13:52.119000+02:00

In my last blog, Preparing for SAP Identity Management’s End-of-Maintenance in 2027, I explained what SAP Identity Management customers should consider as they are preparing for a new identity lifecycle management set-up.

Our collaboration with Microsoft is progressing. The focus is on developing guidance that will enable customers to migrate their identity management scenarios from SAP Identity Management to Microsoft Entra ID. Teams on both sides are closely aligned and working on migration guidelines as well as enhancements of the respective products and services. Together with the German-speaking SAP user group DSAG and several front-runner customers, we are working on best practice guides for a successful migration.

Microsoft recently published the first migration guideline in its Tech Community: SAP Identity Management to Microsoft Entra ID Migration Guidance Now Available. SAP customers who are using SAP Identity Management for cloud and on-premises applications like SAP SuccessFactors, SAP Cloud Identity Services, or Windows Server Active Directory can begin to use Microsoft Entra features such as Conditional Access to enforce Zero Trust access policies, and automatic provisioning that ensures users have the accounts they need for their job role. The guide offers detailed migration guidance for each SAP IDM scenario.

For SAP Identity Management customers who want more guidance on advanced IAM integration scenarios, such as Microsoft Entra ID Governance and the integration with SAP Cloud Identity Access Governance or external IDs, additional in-depth guidance for many areas will be published later this year.

In addition, SAP just published the latest version of the CIO Guide: Identity Lifecycle in SAP Landscapes. This guide explains how identity and access management software from SAP supports building successful system integrations in cloud and hybrid environments.

Vendor creation error after security hardening updates to the system

2024-06-28T16:04:35.970000+02:00

Hi,

We had a session on security hardening done in our ECC system by the SAP Basis team. As it was related to security hardening, from a vendor creation /update process perspective we were not much worried. The assumption was how was security hardening going to impact the process. And we were unpleasantly surprised while we tested in the QA environment.

Initial Analysis

We noticed that vendor update programs were going on error. There are certain programs to convert employee records to vendors. These were the first to go on error.

The error was something as below.

“ File ‘Filename’ is not in directory area ‘File path’ .”

Why the errors started?

As a part of the security guidelines by SAP released in 2021, Logical Path and File Names are to be used to protect Access to the File System. This is a part of feature which was already present before the upgrade. But it was backward compatible and was INACTIVE by DEFAULT. To activate this, we need to maintain the physical path using the transactions FILE (client-independent) and SF01 (client-specific). To add the aliases for the view V_FILEALIA, we can use transaction SM31.

So that security issues due to directory traversal are avoided, it is not possible to specify the target file system for the download directly in the syntax of the operating system. Instead you define one or more target directories as “logical files” and specify them in the configuration of the ABAP download service (see Maintaining Execution Parameters).

What was the config at vendor master which was failing.
The vendor master updation program RPRAPA00 uses path “/interface/<SYS ID>/<A FILE NAME> to update some vendor details in a named file in a file path defined on selection screen. This file path set on screen via variants.

Access to this path was no longer allowed directly, unless configured the way the system expects it.

Steps to maintain the config are as below.

Definition of the logical path name
A logical path name is a platform independent file path. It is assigned to logical file name.
Definition of the logical file name

Logical file name is a platform independent name given to the file in file system. At runtime, the logical file name is converted by the FILE_GET_NAME function module to a platform-specific path and file name. It is assigned a logical path. In programs, the logical file name is usually used to access the physical path.

Assignment of the logical fine name to the physical path

The physical path is assigned to the logical path on system dependence syntax group(OS) level.
A logical path is mapped to physical path as below.

Thus, the vendor programs which were accessing a location “/interface/<SYS ID>/<FILE NAME>, to update vendor records in a named file in the file system were correctly pointed to the correct file.

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

クラウドサービスの災害復旧対応とは？

2024-07-04T13:37:56.721000+02:00

災害インシデント（台風、洪水、火災、地震等）、人為的なインシデント（設定ミス、妨害行為、第三者による意図的なセキュリティ事象等）、及び環境インシデント（機器故障、ソフトウェアエラー、通信ネットワークの切断、停電等）によるITサービスの停止からいち早く復旧することは、企業が被る損害及び被害を抑えるために重要なことです。オンプレミスであれば企業がITシステムを運営・管理するため費用面での折り合いは必要なもののある程度は企業が望む復旧計画を立てることができます。しかし、クラウドサービスではクラウドサービスプロバイダがシステムの運用・管理を担っているため、企業が望む復旧計画を立てることが難しい場合があります。そのため、クラウドサービスを利用する企業においては使用するクラウドサービスの災害復旧を理解しておく必要があります。
本ブログではクラウドサービスの災害復旧を理解する上で必要なポイントについて説明していきます。

災害復旧の重要な要素
災害復旧は、迅速にITサービスをインシデントが起きる前と変わらない状態に復旧することを目的としております。その目的を達成する上で欠かせない2つの要素があります。また、その要素はクラウドサービスを利用する企業において重要なものですので、確認をしておくことをおすすめします。

・目標復旧時間（RTO）
RTOはクラウサービスプロバイダが提供するクラウドサービスが復旧するまでに要する時間です。そのため、RTOを知ることでクラウドサービス利用者は事業の再開までの計画を事前に立てることができ、また復旧までの対策や対応も立ておくことができると思います。
また、クラウドサービスプロバイダは示すRTOが達成できない場合、クラウドサービス利用者へ大きな影響を与えてしまいます。クラウドサービスプロバイダは災害復旧における計画を立て、それに従い迅速な復旧を行うための体制を整えるとともに、ITシステムの冗長化などによる備えもしておかなければなりません。

・目標復旧時点（RPO）
RPOはインシデント発生が発生しクラウドサービスが停止した場合に失われるデータの量を示す指標です。例えばRPOが1時間となる場合、クラウドサービス利用者は最大でインシデント発生時点から1時間前までのデータを失うことになります。データ損失を少しでも抑えるため、RPOを短くすることが望ましく、そのためにはバックアップの頻度が重要となります。バックアップをリアルタイムに実施できれば、理論的にはRPOもゼロとなりデータ損失は発生しないとなります。しかし、複雑な処理やデータ量が多い場合、リアルタイムにバックアップを取ることが難しいこともあります。そのため、クラウドサービス利用者はクラウドサービスの特性や性能を理解した上で、RPOを許容していただくことも必要になります。

災害復旧においてRTOとRPOは大事な指標になります。この2つの要素を知ることで、インシデント発生時における対策や対応も事前に立てておくことができます。また、これらの要素はクラウドサービスプロバイダ側の災害復旧計画の見直しやITシステムの変更などにより変わる可能性もあるため、クラウドサービスを利用する企業においては導入後の定期的な確認を行うことをおすすめします。

災害復旧計画
先に説明したRTO及びRPOの目標数値において、クラウドサービスプロバイは災害復旧計画に基づき決めております。そのため、クラウドサービスプロバイはクラウドサービスにおける最適な災害復旧計画の作成を行う必要があります。この災害復旧計画は基本的に計画の作成、実装、継続的なメンテナンスとテストという3つの要素で構成されており、3つの要素について説明していきたいと思います。

・計画の作成
災害復旧計画の作成にはいくつかの重要な構成要素があります。主な構成要素は以下となります。

・災害復旧計画の定義とポリシ：
計画が網羅するクラウドサービス、プロセス、機能等を明確にするために、災害復旧計画の目的、範囲、目標を定義したポリシを決める必要があります。また、策定したポリシにおいてはクラウドサービスプロバイダの経営陣によるコミットメントを含めておくことも重要となります。

・役割と責任：
策定した定義とポリシをつつがなく遂行するために必要なチームを編成し、必要な役割と責任を定義していきます。また、災害復旧に対応するチームは、クラウドサービスを利用する企業とのコミュニケーションチャンネルの開設を行います。

・重要度評価とビジネスインパクト分析：
クラウドサービスを提供する上で必要不可欠なプロセスやシステムなど、また安定して提供する上で必要なリソース要件を特定し、重要度を付けています。その後、必要不可欠なプロセスやシステム及びリソースに対してビジネスインパクト分析を行い、分析結果に従い災害復旧に必要なリソースへの投資、復旧要件（RTO及びRPOの目標数値など）、及び復旧方針などを決めています。

・リスク評価とリスク分析：
初めにすべての資産をリストし、それらの資産に関連する脅威と脆弱性を調査します。その後、脅威と脆弱性の各組み合わせの影響と可能性を評価し、リスクのレベルを計算します。最後にリスクレベルに応じた情報セキュリティリスクの管理及びリスクから保護するためのコントロールの実装に関する適切なアクションと優先順位などを決めていきます。尚、リスク評価とリスク分析においては、ISO27001やNISTなどを基にすることで実施の内容に一定の安心を得ることができます。

・データのバックアップと復元
データのバックアップと復元はRTO及びRPOに大きな影響を与えるため、とても重要なものとなります。データをバックアップにおいては、ロケーション、頻度、及び方法などを決めます。特にバックアップの頻度はRPOに直接影響を与えるため、重要となります。理想はリアルタイムバックアップとなりますが、トランザクションやデータ量などによってはリアルタイムが難しい場合も出てくるため、各クラウドサービスの性質に合わせて最適な頻度を決めていきます。
バックアップの復元はRTOに直接影響を与えるため、復元の範囲、優先順位、及び手順を日頃から確認しておく必要があります。

・計画の実装
計画の作成で策定した内容をクラウドサービスへ実際に落とし込んでいきます。例えば、重要度評価とビジネスインパクト分析では、クラウドサービスを安定して提供する上で必要なリソース要件を特定し、重要度を付け、クラウドサービスを利用する企業へのビジネスインパクト分析を行います。また、データのバックアップと復元においては、バックアップのロケーションを同じ地域内にある別の建屋にするのか又は離れた地域にするのか、またクラウドサービスの性質及びリソースに合わせて実際のバックアップ頻度を決めていきます。この実装においては作成で決めた内容をクラウドサービスへ当てはめていく作業となります。

・計画のテスト
テストスの目的は、計画の作成が実装され、それが有効的であるかを確認すること、災害復旧が発生したとして計画の作成で決めた内容どおりに災害復旧が行えることの証明、及び災害復旧計画の準備と成熟度を向上させることです。そのため、テストは少なくとも年に1回は実施することが最適とされ、またそのテスト結果を踏まえ、計画の作成の見直しを行い、よりよいものへ改善を行うことが重要となります。

クラウドサービスプロバイにおいて災害復旧計画は、インシデント発生時に速やかにクラウドサービスを復旧するために必要なプロセス、対応範囲、目標などを決める上で不可欠なものです。また、クラウドサービスを利用する企業に対してインシデント発生時の復旧対応に関する情報（RTO、RPO、復旧対応の内容、及びコンタクト先等）を提供する上でも欠かせないものとなります。

災害復旧とSAP
SAPはNIST、ISO 22301及びISO 27001などの国際規格を基に災害復旧計画を策定しております。策定した災害復旧計画に従い各クラウドサービスの管理部門が災害復旧の対策を実施していることを外部監査で確認を行っております。
また、SAPが提供するクラウドサービスのRTO及びRPOは各クラウドサービスが提供するサービス内容、リソース、及び性質により異なるためここでの紹介は控えますが、お客様の業務への影響を最小限に抑えるため、様々な対策を講じていることをお約束します。

New free Learning Journey “Implementing Authorizations in SAP BW/4HANA””

2024-07-08T10:15:46.802000+02:00

After starting your SAP BW/4HANA journey either from scratch with our beginner learning journey or with existing SAP BW/4HANA skills, it is now time to learn how to ensure data security and access control in SAP BW/4HANA.

For that, SAP BW/4HANA uses authorizations, which are permissions granted to users to access specific data or perform certain actions within the system.

This self-paced learning journey is designed for SAP BW/4HANA consultants and administrators who want to learn how to define and implement these authorizations in SAP BW/4HANA.

It's also suitable for authorization administrators in SAP ERP or SAP S/4HANA who are extending their responsibility for authorizations to SAP BW/4HANA.

It will equip you with the skills to:

Differentiate between transactional and analytical security needs in SAP BW/4HANA
Create and maintain analysis authorizations
Create authorizations for Data Modelers, and Data Load Administrators, and 
Trace standard and analysis authorizations.

As you embark on your SAP BW/4HANA journey, remember that continuous learning is key.

Ensure data security and access control in SAP BW/4HANA!

Your Product Learning CoE Analytics Team

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)