SAP Pharma Network Onboarding Guide

Transcription

1 Onboarding Guide - Final Review SAP Pharma Network Document Version:

2 Typographic Conventions Type Style Example Description Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Textual cross-references to other documents. Example EXAMPLE Example Example <Example> Emphasized words or expressions. Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE. Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. EXAM PLE Keys on the keyboard, for example, F2 or EN TER SAP SE or an SAP affiliate company. All rights reserved. Typographic Conventions

3 Document History Version Status Date Author/Contributor Change 0.18 Draft AR Final Review Document History 2016 SAP SE or an SAP affiliate company. All rights reserved. 3

4 Contents 1 About This Document Purpose and Scope Target Audience Onboarding to the SAP Pharma Network Statement of Work (SOW) Onboarding - A Collaborative Process Overview of the Onboarding Process Phase 0: Pre-Onboarding Phase 1: Test Onboarding Phase 2: Production Onboarding Phase 3: Service Activation Overview of Connection Setup Scenario Overview Inbound and Outbound Communication Tasks and Roles Collaboration Platform Offboarding Communication Patterns Push/Pull Push/Push Communication Pattern Permutations Scenario 1: Both Participants Leverage Push/Pull Scenario 2: Both Participants Leverage Push/Push Scenario 3: Push/Pull to Push/Push SFTP Scenarios SFTP Server@Participant Required Keys Required Certificates SFTP Server@SAP SFTP Server@SAP and SFTP Server@Participant Information to Provide During Onboarding Shared Artifacts By Participant to SAP Security Elements By SAP to Participant Connectivity Elements to Provide to SAP Connectivity Elements Provided by SAP How Artifacts Relate to Integration Flow Configuration Transport Level Security Message Level Security SAP SE or an SAP affiliate company. All rights reserved. Contents

5 6 Security Requirements Onboarding Security Requirements for Test Environment Web Service Based Security Requirements SFTP Based Integration Security Requirements Security Requirements for Production Environment Web Service Based Security Requirements SFTP Based Integration Security Requirements How Security Elements Relate to Mail Adapter Security Certificates and Encryption Standards SAP Pharma Network Trusted Certificate Authorities Content Encryption Supported Standards PGP Content Encryption (Supported Algorithms) PKCS#7 Content Encryption (Supported Algorithms) Content Signing Supported Standards PGP Content Signing PKCS#7 Content Signing Glossary Support SLAs BCP Ticket Queues Important Disclaimers and Legal Information Contents 2016 SAP SE or an SAP affiliate company. All rights reserved. 5

6 1 About This Document 1.1 Purpose and Scope This document provides: An overview of the SAP Pharma Network, the Onboarding Process, available communication patterns and security requirements, as well as details of the types of data and artifacts shared during onboarding. System specific technical implementation guidance to onboard to the SAP Pharma Network Generic information which is relevant regardless of your system topology Information specific to your backend system whether SAP or non-sap 1.2 Target Audience This document is for the technical implementation team involved in integration and onboarding with the SAP Pharma Network, including: Implementation and integration teams System Administrators Information Security Officers Network Administrators BASIS Administrators (in the case of SAP Backend Systems) Related Documentation Introduction to the SAP Pharma Network SAP Pharma Network Configuration Guides SAP SE or an SAP affiliate company. All rights reserved. About This Document

7 2 Onboarding to the SAP Pharma Network Connecting a participant to the SAP Pharma Network is known as onboarding. To onboard successfully, SAP experts, who are part of the SAP Pharma Network Onboarding Team, work with experts from your organization. Working with you, we perform tasks in a coordinated way and exchange data at several steps of the process. 2.1 Statement of Work (SOW) The standard onboarding process is based on a Statement of Work (SOW) agreed between each participant and SAP. After the SOW has been documented, a participant signs a contract for SAP Pharma Network Onboarding. The onboarding process is then initiated by SAP. All experts involved in the onboarding process follow a clearly defined process, and exchange information in a coordinated and secure manner on a collaboration platform. Before two participants can start collaborating with each other on the SAP Pharma Network, both participants must be connected to the SAP Pharma Network. Each SAP Pharma Network participant is onboarded to a Test and Productive landscape. A participant is onboarded to the SAP Pharma Network when the connection to a simulated participant has been set up, and the desired integration flows run across this connection. Onboarding is a one-time activity that is a prerequisite for service activation. Onboarding to the SAP Pharma Network 2016 SAP SE or an SAP affiliate company. All rights reserved. 7

8 2.2 Onboarding - A Collaborative Process The following figure illustrates the collaborative aspect of the onboarding process: Participant Integration Team Configuring backend system Setting up connection to SAP Pharma Network SAP Pharma Network Onboarding Team Setting up SAP Pharma Network environment for participant Setting up connection to participant system Designing integration content SAP SE or an SAP affiliate company. All rights reserved. Onboarding to the SAP Pharma Network

9 2.3 Overview of the Onboarding Process The following figure shows the interfaces and steps of the onboarding process: SAP Pharma Network Onboarding Process Participant SAP Pharma Network Onboarding Team Kickoff Meeting Define Project Set Up and Scoping SOW Document Provision TEST and PRODUCTIVE SAP Pharma Network Landscapes Collaboration Platform Provisioned Mail Invite To Collaboration Platform Prepare Security And Integration Artefacts and other Data for Chosen Connectivity Option Configure Back-End System (TEST) <<Confirm Completion>> Design Integration Content Update and Deploy Security And Integration Artefacts on Tenant Cluster <<Enables>> Connectivity and Content Testing on TEST Landscape <<Post Sign Off>> Configure Back-End System (PRODUCTION), Sharing Integration Content Design SAP Pharma Network Integration Content Update and Deploy Security and Integration Artefacts on Tenant Cluster <<Enables>> Connectivity and Content Testing on PRODUCTIVE Landscape Sign Off Onboarding to the SAP Pharma Network 2016 SAP SE or an SAP affiliate company. All rights reserved. 9

10 2.3.1 Phase 0: Pre-Onboarding As a precursor to onboarding, each participant receives the SAP Pharma Network Onboarding Questionnaire. This contains all integration options available, including considerations related to the onboarding scope. During this phase, the following activities take place: Activity SAP delivers the questionnaire, aligns with each participant who returns the completed questionnaire. SAP Pharma Network Onboarding Lead builds the scope and project plan. Primary Responsibility/ Supporting Participant SAP Description The Onboarding Questionnaire contains all technical implementation and messaging options available to each participant. SAP and the participant align to complete the questionnaire. Objective: From the participant point of view, to choose technical and messaging requirements. For the SAP Pharma Network Onboarding Team, the input from the Onboarding Questionnaire is vital to create an accurate, representative project schedule and scope definition. The scope of the participant s onboarding depends on the participant s integration requirements, described in the Onboarding Questionnaire. The SAP Pharma Network Onboarding Lead generates the project scope and corresponding project schedule using the questionnaire as input. Objective: Create an accurate and representative project schedule and scope definition used for monitoring and control throughout the onboarding process. Environment Provisioning SAP The SAP Pharma Network Onboarding Team provision the participant s required Test and Production environments. Objective: Provision the participant s tenants in the SAP Pharma Network. Collaboration Platform Provisioning SAP The SAP Pharma Network Onboarding Team provision the collaboration platforms used during onboarding and invite the participant s implementation team and stakeholders. Objective: Provision the SAP Jam collaboration platform which allows us to SAP SE or an SAP affiliate company. All rights reserved. Onboarding to the SAP Pharma Network

11 Activity Primary Responsibility/ Supporting Description share all onboarding technical and administrative artifacts. For more on the SAP Jam, see Section 2.6. Readiness Check Participant/SAP The SAP Pharma Network Onboarding Team and the participant implementation and technical teams align, and perform system readiness checks to confirm that the participant system is technically ready to integrate with the SAP Pharma Network. Objective: Ensure that the participant backend system meets all baseline technical criteria to onboard to the SAP Pharma Network. This readiness check prevents potential blocks and delays to onboarding due to an under-provisioned or misconfigured participant system. Related Documentation SAP Pharmacy Network Onboarding Readiness Guides Phase 1: Test Onboarding During this phase the participant s backend system is connected to the SAP Pharma Network Test environment. Integration artifacts are traded between the participant and the SAP Pharma Network Onboarding team. Artifacts include: Keys Endpoints WSDL files Certificates IP ranges After successful establishment of technical connectivity, message testing activity is carried out, based on a mutually accepted test suite. Onboarding to the SAP Pharma Network 2016 SAP SE or an SAP affiliate company. All rights reserved. 11

12 Simulated Tenants and Backend Systems Before two participants can communicate productively, test connections are set up to a simulated tenant and simulated backend system, as follows: Between Participant A's back-end system and Participant A's tenant in the SAP Pharma Network Between Participant A's tenant in the SAP Pharma Network and a simulated Participant B tenant in the SAP Pharma Network Between simulated Participant B tenant in the SAP Pharma Network and a simulated Participant B backend system The following figure shows the process. The main activities in this phase are outlined below. Activity Technical Integration Establishment of Basic Connectivity Establishment of Basic Connectivity Validation Primary Responsibility/ Supporting Participant/SAP Participant/SAP Description This activity includes trading integration data and security and network artifacts using the SAP Jam platform. The participant provides artifacts to the SAP Pharma Network Onboarding team who configure the participant Test environment. The participant consumes SAP artifacts on the participant s backend system. Objective: Establish technical connectivity between the participant backend system and the SAP Pharma Network Test landscape. This activity includes the validation of basic technical connectivity and bidirectional message throughput between the participant system and the SAP Pharma Network by means of ping. Objective: Ensure that basic technical connectivity and bidirectional message throughput is possible. Also validates that SAP SE or an SAP affiliate company. All rights reserved. Onboarding to the SAP Pharma Network

13 Activity Primary Responsibility/ Supporting Description the participant backend system is fully enabled from a technical perspective, by inference validating that message processing, throughput and security functions are operating as expected from the vantage point of the participant system and the SAP Pharma Network Test landscape. Content Development SAP/Participant In the event that the participant requires SAP Pharma Network to transform messages, the participant specific integration content is built based on the participant s messaging requirements. Objective: Create participant specific integration content if required by the participant. Content Testing Participant/SAP This activity includes the alignment between SAP and the participant to agree a meaningful and representative Test Suite to validate the messaging requirements of the participant. SAP provides a base Test Suite that the participant can add to. Testing activity is based on these test cases, and monitored and tracked accordingly. This is a mandatory step before Review and Signoff of the Test onboarding phase. Objective: Agree a representative and meaningful Test Suite, giving confidence to SAP and the participant that all participant messaging requirements are adequately tested and verified. Review and Sign-Off Participant/SAP This activity is a formal review and signoff of the Test onboarding. After review of the onboarding and the completed Test Suite, SAP and the participant sign-off that Test onboarding has been completed to the satisfaction of both parties, and Productive onboarding can begin. Objective: Formally sign off on Test onboarding by means of a formal review. Uncovers potential concerns or need for additional testing before the Production onboarding is started. Onboarding to the SAP Pharma Network 2016 SAP SE or an SAP affiliate company. All rights reserved. 13

14 2.3.3 Phase 2: Productive Onboarding This phase includes the technical integration of the participant s production backend system to the SAP Pharma Network Production environment. Following the Test onboarding phase, in which the participant s messaging requirements were systematically tested, the validated integration content is promoted to the SAP Pharma Network Production environment. The participant s backend system is technically integrated to the SAP Pharma Network Production environment, culminating in validation testing. At this point, the participant is considered to be live and productive in the SAP Pharma Network. The core activities in this phase include: Activity Backend System Transports/Promotion Technical Integration Establishment of Basic Connectivity Primary Responsibility/ Supporting Participant/SAP Participant/SAP Description This activity involves promotion and transports on the participant s backend system, and also within the Pharma Network Cloud Environment. If applicable, the participant transports and promotes the configurations which were validated and signed-off during Test onboarding, for example, SAP BASIS Transports in the case of a participant using a SAP backend system. The Pharma Network Onboarding team promote the validated integration content, which was validated during Test onboarding, to the Production landscape. Objective: Reuse and promote those elements on the SAP and participant side, which have been previously validated and mutually signed-off, in the Production landscape. This activity includes the trading of integration related data and artifacts (security and network) using the SAP Jam platform. The participant provides these artifacts to the Pharma Network Onboarding team, who configure the participant provisioned environment accordingly. The participant consumes SAP artifacts on their backend system. Artifacts include keys, WSDLs, certificates, endpoints and so on. Objective: Establish technical connectivity between the participant backend system and the SAP Pharma Network within the Production landscape SAP SE or an SAP affiliate company. All rights reserved. Onboarding to the SAP Pharma Network

15 Activity Establishment of Basic Connectivity Validation Primary Responsibility/ Supporting Participant/SAP Description This activity includes the validation of basic technical connectivity and bidirectional message throughput between the participant system and the SAP Pharma Network Production environment by means of ping. Objective: Ensure that basic technical connectivity and bidirectional message throughput is possible. Validates that the participant backend system is fully enabled from a technical perspective, by inference validating that message processing, throughput and security functions are operating as expected, from the vantage point of the participant system and the SAP Pharma Network Production landscape. Validation Content Testing Participant/SAP This activity includes the alignment between SAP and the participant to agree a meaningful and representative test suite to validate production level message exchange between the participant s production backend system and the SAP Pharma Network Production landscape. Objective: Validate the bidirectional transmission and consumption of production grade data within the SAP Pharma Network Production landscape. Review, Sign-Off, Go-Live Participant/SAP This activity is a formal review and signoff of Production onboarding. After review of the onboarding process and of the completed Test suite, SAP and the participant sign-off that Production onboarding has been completed to the mutual satisfaction of both parties, and go-live is authorized. Objective: Formally sign off on the Production onboarding by means of a formal review. Uncovers potential concerns or need for additional testing before go-live can be considered, and service activation executed. Onboarding to the SAP Pharma Network 2016 SAP SE or an SAP affiliate company. All rights reserved. 15

16 2.3.4 Phase 3: Service Activation When at least two participants have onboarded to the SAP Pharma Network in a productive capacity, that is, the participant s productive backend systems have been integrated to SAP Pharma Network, the participant productive tenants are detached from simulated tenants, and both participants productive tenants are connected to each other. This is known as service activation. After service activation, both participants can start collaboration in a productive capacity over the SAP Pharma Network. The following figure illustrates the processes: 2.4 Overview of Connection Setup Setting up a secure connection between a participant system and a tenant includes tasks associated with the configuration of the sender/receiver system and the tenant. This involves different people and roles SAP SE or an SAP affiliate company. All rights reserved. Onboarding to the SAP Pharma Network

17 2.4.1 Scenario Overview Inbound and Outbound Communication We assume a specific setup of technical components and communication paths, that is, a participant system is connected to one of the SAP Pharma Network tenants assigned to that participant. The connection can be made regardless of system topology, for example, ECC, ECC+PI, and so on. The terms inbound and outbound refer to the perspective of the SAP Pharma Network: Inbound refers to message processing from a participant system to SAP Pharma Network where SAP Pharma Network is the server. Outbound refers to message processing from SAP Pharma Network where SAP Pharma Network is the client. 2.5 Tasks and Roles The tasks required to configure the communication paths are outlined in the table below. The tasks depend on the participant s choice for each communication path regarding: Chosen security level Communication pattern Protocol Task Providing tenant cluster (provisioning participant tenants in the Pharma Network) Configuring inbound communication Description Covers the initial provisioning of the tenant and starting the tenant cluster for the participant (done by SAP). Covers the following sub tasks: Configuring the sender system to enable the sender to securely send messages to the tenant Onboarding to the SAP Pharma Network 2016 SAP SE or an SAP affiliate company. All rights reserved. 17

18 Task Description This step includes the configuration of the required security artifacts for the sender system, for example, a keystore with keys for the chosen security option. Configuring the integration platform and the tenant to accept messages received from the sender. A load balancer is used to accept inbound calls and dispatch them to the correct runtime node (assigned to the related tenant). Therefore, the security configuration of the sender system must be in accordance with the load balancer configuration provided by SAP. For example, when certificate-based authentication is used, (general scenario for web services based integrations), the sender administrator must ensure that the keystore of the sender contains a client certificate accepted by the load balancer. Configuring the related integration flow An integration flow defines how the message from the sender is processed on the tenant. To round-up the configuration of inbound communication, certain settings have to be made for the related integration flow. If message-level security is configured so that the message received from the sender is encrypted, it is necessary to add a Decryptor step to the related integration flow. Configuring outbound communication Covers the following sub tasks: Configuring the receiver system to accept messages received from the tenant This step includes the configuration of the required security artifacts for the receiver system, for example, a keystore with keys for the chosen security option. Configuring the tenant to securely send messages to the receiver This step typically includes the creation and deployment of certain security artifacts. A security artifact can be a tenant keystore or a user credential artifact. Configuring the related integration flow To round up the configuration of outbound communication, certain settings have to be made for the related integration flow SAP SE or an SAP affiliate company. All rights reserved. Onboarding to the SAP Pharma Network

19 2.6 Collaboration Platform The centralized collaboration platform used during onboarding to the Pharma Network is SAP Jam. SAP Jam is a collaboration and decision-making solution which is delivered to each participant prior to technical onboarding. The team provisions a separate platform for Test and another for Production. The Pharma Network Onboarding team invite all participant stakeholders to join the platform. The team populates the SAP Jam with the most up-to-date documentation and support resources. The SAP Jam stores: All integration artifacts, including certificates, keys, WSDLs, endpoint URLs Project Management artifacts used to track onboarding progress Testing Artifacts, such as Test suites and cases The benefits of using SAP Jam include: SAP Jam is a secured and centralized collaboration platform All onboarding technical and administrative data is hosted in the SAP Jam for the duration of the onboardings. This facilitates easy access and a more secure and localized approach. SAP Jam includes activity feeds with user status updates, along with the ability to configure custom notifications on a prescribed frequency to a prescribed list of stakeholders. SAP Jam allows for the easy archiving and retrieval of bulk data through click archiving and downloading of all content. Related Documentation Offboarding SAP have established an effective and efficient offboarding process which respects industry best practice with regards to information security. For further information, contact the SAP Pharma Network Onboarding team. Onboarding to the SAP Pharma Network 2016 SAP SE or an SAP affiliate company. All rights reserved. 19

20 3 Communication Patterns The SAP Pharma Network supports two communication patterns: Push/Pull Push/Push Each participant can choose which to use. A participant can connect with another participant, where each participant uses a different communication pattern to interface with the SAP Pharma Network. This section outlines the communication patterns and use cases. 3.1 Push/Pull In a Push/Pull communication pattern, the participant system pushes data to the SAP Pharma Network using web services or SFTP, and then pulls response data from the SAP Pharma Network. In this communication pattern, the participant system always acts as a client. The participant acts as a client, initiates a connection to the SAP Pharma Network, and pushes data. Then, the participant continues to act as a client by pulling data from the SAP Pharma Network. This approach is favored by participants who cannot or do not wish to expose their systems to the internet. Also, the participant system does not need to maintain a server keystore for inbound web service calls. Push/Pull is shown below: SAP SE or an SAP affiliate company. All rights reserved. Communication Patterns

21 3.2 Push/Push In this communication pattern, the participant system pushes data to the SAP Pharma Network using web services or SFTP. The SAP Pharma Network then pushes response data to the participant s system. In this communication pattern, the participant system acts as client and server. The participant acts as a client, initiates a connection to the SAP Pharma Network, and pushes data. The SAP Pharma Network then pushes data to the participant which acts as a server. This approach is favored by participants who can expose systems by leveraging SAP PI, or an OER/ATTP system using NAT. This approach requires the participant system to leverage both client and server keystores. Push/Push is shown below: 3.3 Communication Pattern Permutations The Pharma Network supports the following patterns for communication for sending and receiving messages: Communication Patterns 2016 SAP SE or an SAP affiliate company. All rights reserved. 21

22 3.3.1 Scenario 1: Both Participants Leverage Push/Pull In this scenario the sending system pushes the data to the Pharma Network using a web service. The message reaches the sender tenant through a web services PUSH. After processing of data, the Sender Tenant sends the data through a web service to the Receiver tenant (PUSH). The data is then stored in a temporary data store on the receiving tenant. The receiving system pulls the data from the data store. In summary, there is a PUSH process from the Sending participant to the Pharma Network, and a PULL process from the Receiver participant from the Pharma Network. For this reason, the process is referred to as PUSH/PULL. The following figure shows the process: Considerations: the PUSH/PULL mechanism is generally used when the receiver system cannot expose its interface outside the firewall. Some participants do not wish to expose their service end points outside their organization. The PULL mechanism allows them to pull data from the data store in their tenant. This requires a DNS/IP endpoint for inbound messages from the Pharma Network. Therefore, SAP WebDispatcher/Netweaver PI must be installed Scenario 2: Both Participants Leverage Push/Push In this scenario, the sending system pushes the data to the Pharma network using a web service. The messages reach the sender tenant through a web service (PUSH). After processing of data, the Sender Tenant sends the data using a web service to the Receiver tenant (PUSH). The Receiver tenant then sends the data to the Receiver system using a web service (PUSH). In summary, there is a PUSH process from the sending participant to the Pharma Network, and a PUSH process from the Receiver tenant on the Pharma network to the Receiver system from the Pharma Network. The process is referred to as PUSH/PUSH. The following figure shows the process: SAP SE or an SAP affiliate company. All rights reserved. Communication Patterns

23 Considerations: PUSH/PUSH mechanism is provided to participants who want synchronous or near synchronous transmission. The Pharma Network provides error handling in cases where the receiving service is down. The Pharma Network reprocesses the message a number of times until successful delivery, or else stores and flags the message. You select the number of retries, and the SAP Onboarding Team implement it Scenario 3: Push/Pull to Push/Push In this scenario, one participant (sending or receiving) uses a PUSH/PUSH mechanism and the other uses a PUSH/PULL mechanism. Each participant on the network decides what communication patterns they wish to use. Different participants can use different communication types. When communicating with each other, one participant can use one communication type, and the other participant uses a different communication type. The following figure shows the process: Considerations: In cases where the first participant pushes the message to the network they cannot assume that the message will be synchronously received by the receiver if the receiver uses the Pull mechanism. The Pull frequency can be set high, so that it is similar to a synchronous process. The polling parameter is set in the backend. Communication Patterns 2016 SAP SE or an SAP affiliate company. All rights reserved. 23

24 4 SFTP Scenarios The SAP Pharma Network supports the following SFTP scenarios: Table 6: Overview of SFTP Scenarios Use Case System Landscape Transport Level Security SFTP SFTP An SFTP server is hosted by the participant, and the SAP tenant acts as SFTP client. An SFTP server is hosted by SAP, and the SAP tenant and the participant system act as SFTP client. SSH File Transfer Protocol (SFTP) SFTP (hybrid scenario) This scenario is a combination of the first two scenarios SAP SE or an SAP affiliate company. All rights reserved. SFTP Scenarios

25 Participant A 4.1 SFTP Server@Participant You can set up SFTP-based communication between a participant and the SAP Pharma Network with an SFTP server hosted by the participant. The following figure illustrates the system landscape. Pushing files to SFTP server SAP SAP Pharma Network Participant B Participant Tenant A Participant Tenant B R R SFTP Server SSH R R Direction of request Pushing files from SFTP server Direction data flow Participant A sends a message to Participant B. The SAP Pharma Network processes the message, and then sends it to the receiver's tenant which, as SFTP client, writes the SFTP message to the SFTP server on the receiver side. For the data flow in the other direction, Participant Tenant B, as SFTP client pulls data from the SFTP server and forwards the data to Participant A through Tenant A. During the Test phase, SAP creates simulated tenants and simulated participant systems in a test environment to test message processing. SFTP Scenarios 2016 SAP SE or an SAP affiliate company. All rights reserved. 25

26 Participant A Firewall Required Keys The following figure shows an overview of the required keys on the SAP side and on the participant side. SAP Pharma Network Participant B Participant Tenant A Participant Tenant B R SSH SFTP Server Public + private key of Tenant B Deployed on Participant Tenant B Public + private key of SFTP server@participant Required SSH Keys Public key of SFTP server Part of Pharma Network known_hosts file deployed on Tenant B Public key of Participant B Part of authorized_keys file (SFTP server) SAP SE or an SAP affiliate company. All rights reserved. SFTP Scenarios

27 Participant A Firewall Required Certificates Client certificate of tenant A (public and private key) Server root certificate of SAP Pharma Network (BigIP) Client root certificate of SAP Pharma Network Server root certificate of participant (of participant CA) Client certificate of tenant B (public and private key) Server root certificate of SAP Pharma Network (BigIP) Client root certificate of SAP Pharma Network Required SSL Certificates SAP Pharma Network Participant B R Participant Tenant A Participant Tenant B SSH SFTP Server Public + private key of Tenant B Deployed on Participant Tenant B Public + private key of SFTP server@participant Required SSH Keys Public key of SFTP server Part of Pharma Network known_hosts file deployed on Tenant B Public key of Participant B Part of authorized_keys file (SFTP server) To ensure secure data transfer between the components, asymmetric SSH key pairs encrypt and decrypt the symmetric keys that secure the data transfer session between two components (session keys). The following table summarizes how the different keys are related to each other and what role they play in the secure SSH connection process. Note Separate key sets are used for test and production. SFTP Scenarios 2016 SAP SE or an SAP affiliate company. All rights reserved. 27

28 Table 7: Required SSH Keys Keystore Key Description Participant tenant keystore Private SSH key of tenant Generated by SAP and remains in keystore. Required for communication with the participant client. Deployed on the participant tenant. Public SSH key of tenant Generated by SAP and given to participant who stores this key in the authorized_keys file on the SFTP server. Participant keystore Required for communication with the SAP Pharma Network (tenant). Public SSH key of SFTP Generated by the participant and given to SAP. SAP stores this public key in the known_hosts file related to the tenant and deploys it on the tenant. To implement this setup, the required key pairs must be generated on each side of the communication and the public keys exchanged with the corresponding counterpart SAP SE or an SAP affiliate company. All rights reserved. SFTP Scenarios

29 Testing Phase During the testing phase, additional SSL certificates are required to enable secure communication between the simulated back end systems and simulated tenants. Table 8: Keystore Key Description Simulated Participant A tenant keystore Required for communication with simulated Participant A system and with Participant B tenant. Deployed on the simulated Participant A tenant. Simulated Participant A tenant client certificate SAP Pharma Network client root certificate SAP Pharma Network server root certificate (of BigIP) Required to authenticate the simulated Participant A tenant as sender of messages. Contains the public and private key and is signed by TCTrustCenter. Required to authenticate Participant B tenant as sender of messages. The same root certificate is used for both the simulated Participant A tenant and Participant B tenant. The following root certificate is used: TC TrustCenter Class 2 CA II. Required for inbound processing at simulated Participant A tenant when called by Participant B tenant. Participant A server root certificate (of participant CA) Required to authenticate simulated Participant A system as receiver of messages. Participant B tenant keystore Required for communication with simulated Participant A tenant. Deployed on Participant B tenant. Participant B tenant client certificate SAP Pharma Network server root certificate (of BigIP) SAP Pharma Network client root certificate Required to authenticate Participant B tenant as sender of messages. Contains the public and private key and is signed by a CA. Required for inbound processing at Participant B tenant when called by the simulated Participant A tenant. Required to authenticate the simulated Participant A tenant as sender of messages. The same root certificate is used for both the simulated Participant A tenant and Participant B tenant. SFTP Scenarios 2016 SAP SE or an SAP affiliate company. All rights reserved. 29

30 Participant A The simulated Participant A tenant SSL keystore does not contain any certificates that are specific to the onboarding Participant B, and therefore can be provided during the setup of the simulated Participant A tenant (as prerequisite). Recommendation To keep track of all required and exchanged keys during onboarding and productive operation, we recommend that you adhere to specific key-naming conventions SFTP Server@SAP You can set up SFTP-based communication between a participant and the SAP Pharma Network with an SFTP server hosted at SAP. This topic explains the setup of components and summarizes the keys that need to be exchanged during onboarding. The following figure illustrates the system landscape. Pushing files to SFTP server SAP Pharma Network SAP Participant B Participant Tenant A Participant Tenant B R R SFTP Server SFTP Client SSH R R Direction of request Pushing files from SFTP server Direction data flow Participant B tenant as SFTP client writes a message to the SFTP server. Participant B sends an acknowledgment message to the SFTP server (to a participant-specific inbox). In the other direction, Participant B tenant as SFTP client picks up the message from the SFTP server, from a participant-specific inbox. To ensure secure data transfer between the components, asymmetric SSH key pairs are used to encrypt and decrypt the symmetric keys that are used to secure the data transfer session between two components (session keys) SAP SE or an SAP affiliate company. All rights reserved. SFTP Scenarios

31 The following figure shows the components and required SSH keys. Proxy and Load Balancer for calls reaching the SFTP server Public + private key of SFTP server@sap Public key of Participant B Tenant Associated with mailbox user allocated for a particular participant Public key of SFTP client@participant Associated with mailbox user allocated for a particular participant SAP Pharma Network Participant B Participant A Participant Tenant A Participant Tenant B R SAP SFTP Server R SFTP Client Public + private key of SAP Pharma Network Participant B Tenant Deployed on Participant B Tenant Public key of SFTP server@sap Part of known_hosts file deployed on participant tenant Public + private key of SFTP client@participant Public key of SFTP server@sap Part of known_hosts file of Participant B Testing Phase During testing, additional SSL certificates are required to enable secure communication between a simulated Participant A back end and simulated Participant A tenant, as well as between the simulated Participant A tenant and Participant B tenant. For simplicity, these SSL certificates are not depicted in the figure. In this setup, both the SAP Pharma Network and the Participant B system act as SFTP clients when writing (pushing) or reading (pulling) files to or from the SFTP server. A proxy and a load balancer are interconnected between the Participant B tenant or SFTP client@participant and the SFTP server@sap for calls reaching the SFTP server@sap. These components have the following technical addressing parameters: SSH port 22 (between participant SFTP Client and SFTP Server@SAP) In the test landscape, this port has the following external URL: testintegration.hana.ondemand.com (for data center Rot) testintegration.us1.hana.ondemand.com (for US data center) For the connectivity test, this port is always open and does not require dedicated access requests. SFTP Scenarios 2016 SAP SE or an SAP affiliate company. All rights reserved. 31

32 For productive use, the port has the following external URL: integration.hana.ondemand.com SSH port 5022 (between load balancer and SFTP server) Note The SAP Pharma Network Onboarding team supply you with an up-to-date list of the URLs of the available landscapes. No keys need to be deployed on the load balancer. The required keys are forwarded from the SFTP server. The following table summarizes the different required keys and indicates what role they play in the secure SSH connection process. Note Note that separate key sets are used for test and for productive usage. Table 9: Required SSH Keys Key Private key of SAP Pharma Network participant tenant Public key of SAP Pharma Network participant tenant Description Generated by SAP (and remains there). Associated with the SAP PN mailbox user allocated for a particular participant (tenant) on the SFTP server@sap. Private key of SFTP server@sap Generated by SAP (and remains there). Public key of SFTP server@sap The participant stores this public key in a known_hosts file. SAP stores this public key in the known_hosts file and deploys it on the participant tenant. Private key of SFTP client@participant Public key of SFTP client@participant Generated on the participant side (and remains Associated with the participant mailbox user allocated for the participant on the SFTP server@sap. To implement this setup, the required key pairs must be generated on each side of the communication and the public keys exchanged with the corresponding counterpart. Recommendation To keep track of all required and exchanged keys during onboarding and productive operation, we recommend that you adhere to specific key-naming conventions SAP SE or an SAP affiliate company. All rights reserved. SFTP Scenarios

33 FIrewall FIrewall SFTP and SFTP You can set up SFTP-based communication between a participant and the SAP Pharma Network with SFTP servers hosted both at SAP and at the participant. This is also known as a hybrid use case. This topic explains the setup of components and summarizes the keys to exchange during onboarding. The following figure shows the components and required SSH keys. Public + private key of SFTP server@sap Public key of Participant Tenant B Associated with mailbox user allocated for a particular participant in SFTP server@sap Public + private key of SFTP server@participant Public key of SFTP client@participant Associated with mailbox user allocated for a particular participant on SFTP server@sap Public key of Pharma Network Participant Tenant B Participant B SAP Pharma Network R Push SFTP Server Participant A Participant Tenant A Participant Tenant B R Pull SAP SFTP Server R SFTP Client Push Public + private key of Pharma Network Participant Tenant B Deployed on Participant Tenant B Public + private key of SFTP client@participant Public key of SFTP server@sap Part of known_hosts file Public key of SFTP server@participant Part of known_hosts file Public key of SFTP server@sap Part of known_hosts file of participant Testing Phase During testing, additional SSL certificates are required to enable secure communication between the simulated Participant A back end and the simulated Participant A tenant, as well as between the simulated Participant A tenant and the Participant B tenant. For simplicity, the figure does not show these SSL certificates. See the SFTP server@participant section for more information. In this scenario, the tenant acts as SFTP client in the following cases: When pushing files to the SFTP server@participant When pulling files from the SFTP server@sap SFTP Scenarios 2016 SAP SE or an SAP affiliate company. All rights reserved. 33

34 The SFTP also acts as SFTP client when pushing files to the SFTP As this is a combination of the scenarios SFTP server@sap and SFTP server@participant, additional keys are required and must be exchanged during onboarding. However, for individual keys refer to the topics that describe server@participant and server@sap. In summary, note the following: The SAP Pharma Network participant tenant is connected to the SFTP server@participant. Therefore: o The public key of the participant tenant is required to configure the SFTP server@participant. o The public key of the SFTP server@participant is required to configure the SAP Pharma Network participant tenant. The SAP Pharma Network tenant is connected to the SFTP server@sap. Therefore: o The public key of the tenant is required to configure the SFTP server@sap. o The public key of the SFTP server@sap is required to configure the SAP Pharma Network participant tenant. The SFTP server@sap is connected to the SFTP client@participant. Therefore: o The public key of the SFTP client@participant is required to configure the SFTP server@sap. o The public key of the SFTP server@sap is required to configure the SFTP client@participant SAP SE or an SAP affiliate company. All rights reserved. SFTP Scenarios

35 5 Information to Provide During Onboarding To set up a secure connection between a participant system and the SAP Pharma Network information must be exchanged. This information includes public keys (certificates), WSDLs, and so on. In addition, to enable SAP to perform the service activation between two participants who wish to collaborate using the SAP Pharma Network, additional data must be provided, for example, the participant s Sender and Receiver identifiers, GLN, and so on. The exact list of artifacts depends on the chosen connectivity option and security level. This section provides a general overview. The artifacts are listed in the collaboration platform template available on the SAP Jam. See Section Shared Artifacts The sections which follow describe the artifacts provided by the participant to SAP, and by SAP to the participant during onboarding By Participant to SAP Provided by Artifact Description All participants Participants using a Web-Services integration approach, with a chosen communication pattern of PUSH PUSH Client certificates (SSL) or keys used for authentication or authorization to the Pharma Network (Transport Level Security). Participant Server certificates. Certificates or keys are required to securely connect the participant system to the SAP Pharma Network Tenant. Depending on the integration scenario (that is, web services or SFTP), SSL Certificates or public SSH keys. In this case, the participant backend system assumes the role of server: web service calls originate from the Pharma Network, and call the participant backend system. Participant server certificates are required for the outbound SSL handshake from the Pharma Network. Information to Provide During Onboarding 2016 SAP SE or an SAP affiliate company. All rights reserved. 35

36 Provided by Artifact Description Participants using a web services integration approach, with a chosen communication pattern of PUSH PUSH, and a direct SAP ECC -> Pharma Network or SAP PI -> Pharma Network integration scenario All participants Service user details. Certificates or keys used for Message (Message Level Security). Participant provides a system level service user to facilitate inbound web service calls. Certificates or keys are required to secure transmissions at payload level. In the case of an integration scenario using web services, usually the participant provides X.509 public certificates to SAP, allowing the SAP Pharma Network Tenant to verify the digital signature of the inbound payload, and encrypt outbound payloads. In an SFTP based integration scenario, SAP expects to receive SSH or PGP keys for a similar purpose. All participants Participant Number This is required for the service activation process that occurs later. All participants Test Data Sample data is required for message testing. Sensitive elements are obscured. Participants using an Open Envelope Approach/Mappings Participants using SOAP:WS-RM based web services connections and a PUSH/PUSH communication pattern Sample Data/Messaging Specifications Endpoint WSDL of participant system. For all participants wishing to leverage an open envelope approach, or specifically where Pharma Network performs semantic validation or message transformation mapping, supporting data is required by the participant. This is provided in the form of sample data, and message specifications for non-industry standard or altered message structures used by the participant. In a PUSH/PUSH communication pattern, SAP requires a participant generated WSDL that allows SAP Pharma Network to connect to the participant s backend system SAP SE or an SAP affiliate company. All rights reserved. Information to Provide During Onboarding

37 Provided by Artifact Description Participants using XI based web services connections and a PUSH/PUSH communication pattern. Endpoint address of participant system. In a PUSH/PUSH communication pattern, SAP requires a participant provided endpoint address that allows SAP Pharma Network to connect to the participant s backend system. Information to Provide During Onboarding 2016 SAP SE or an SAP affiliate company. All rights reserved. 37

38 5.1.2 Security Elements Each transport level security option requires a specific set of security elements. The following sections describe how required security elements are distributed among the components involved, such as tenant, and sender and receiver systems Transport Level Security Web Services Integration Security Operation Direction Required By SAP Tenant Administrator to do the following Required by sender/receiver administrator..to do the following HTTPs Certificate Based Inbound (Sender calls tenant) Sender client root certificate Check whether the CA the participant is using is trusted by the load balancer (Server) keystore. Load balancer server root certificate Import into the client keystore of the participant system. HTTPs Certificate Based Inbound (Sender calls tenant) Sender client certificate Configure the authorization check in the integration flow HTTPs Certificate Based Outbound (Tenant calls receiver only valid in PUSH/PUSH scenarios) Receiver server root certificate (to be provided by receiver administrator) Import into the tenant keystore. Tenant client root certificate (to be provided by tenant administrator) Import into the server keystore of the participant system. HTTPs Certificate Based Tenant client certificate (to be provided by tenant administrator) Define the client certificate-touser mapping for the configuration of authorization checks SAP SE or an SAP affiliate company. All rights reserved. Information to Provide During Onboarding

39 Transport-Level Security SFTP Integration Security Operation Direction Required By SAP Tenant Administrator to do the following Required by sender/receiver administrator..to do the following SFTP Outbound (tenant as SFTP client sends a request to a SFTP Server) SFTP server (receiver) public key to be provided by SFTP server (receiver) administrator. Add to known_hosts file. Tenant public key (provided by tenant administrator). Used to authenticate tenant as a trusted SFTP client on the SFTP server side. Add to authorized_keys file on the SFTP side Message-Level Security Web Services Integration Security Operation Direction Protection Method On Tenant. Required by tenant administrator to do the following Required by sender/receiver administrator..to do the following PKCS#7, web services Security, Inbound (sender calls tenant). Decrypt. Tenant public certificate (provided by tenant Import into sender system keystore. XML Digital Signature, administrator). Used to encrypt the message from the sender (that is decrypted by the tenant). Verify Sender public certificate (provided by sender administrator) Import into tenant keystore. Used by the tenant to verify the signature of Information to Provide During Onboarding 2016 SAP SE or an SAP affiliate company. All rights reserved. 39

40 Security Operation Direction Protection Method On Tenant. Required by tenant administrator to do the following Required by sender/receiver administrator..to do the following the message sent from the sender system. Outbound (tenant calls receiver) Encrypt Receiver public key (provided by receiver administrator) Import into tenant keystore Used by the tenant to encrypt the message (sent to the receiver). Sign Tenant public certificate (provided by tenant administrator). Used by the receiver to verify the message sent from the tenant. Import into receiver keystore Message-Level Security SFTP Based Integration Security Operation Direction Protection Method On Tenant Required by tenant administrator to do the following Required by sender/receiver administrator..to do the following OpenPGP/ PGP Inbound (Sender Calls tenant) Decrypt Tenant public key (provided by tenant administrator) Import into sender PGP public keyring. Used to encrypt the message from the sender (that is to be encrypted by the tenant) SAP SE or an SAP affiliate company. All rights reserved. Information to Provide During Onboarding

41 Security Operation Direction Protection Method On Tenant Required by tenant administrator to do the following Required by sender/receiver administrator..to do the following To make sure that the public key originates from the correct source and that it has not been changed on its way, consider the note below this table Verify Sender public key (provided by sender administrator) Used by the tenant to verify the signature of the message sent from the sender system. Import into tenant PGP public keyring. To ensure that the public key originates from the correct source and that it has not been changed on its way, see the note below this table Outbound (tenant calls receiver) Encrypt Receiver public key (provided by receiver administrator) Used by the tenant to encrypt the message (sent to the receiver). Import into tenant PGP public keyring. To ensure that the public key originates from the correct Information to Provide During Onboarding 2016 SAP SE or an SAP affiliate company. All rights reserved. 41

42 Security Operation Direction Protection Method On Tenant Required by tenant administrator to do the following Required by sender/receiver administrator..to do the following source and that it has not been changed on its way, see the note below this table. Sign Tenant public key (provided by tenant administrator) Import into receiver PGP public keyring. Used by the receiver to verify the message sent from the tenant. To ensure that the public key originates from the correct source and that it has not been changed on its way, see the note below this table Note This is relevant for the SAP-managed operating model. When you exchange public PGP keys, note the following: o To ensure that the information originates from the correct source and is unchanged during transmission, the key must be exchanged using a secure channel, for example, encrypted . o If a secure channel is not available, the person who receives the public key from the key owner must verify the fingerprint of the public key. One option is to phone the owner of the public key and compare the fingerprint SAP SE or an SAP affiliate company. All rights reserved. Information to Provide During Onboarding

43 5.1.3 By SAP to Participant The table below lists the artifacts provided by SAP to the participant during onboarding. Provided by To Participant Type Artifact Description SAP All SAP Pharma Network test suite This test suite forms the basis of the message testing activity on both the Test and Production landscapes. It is enriched based on mutual agreement with the participant. SAP All participants leveraging web services connections SAP Pharma Network IP Ranges and URLs SAP provides whitelisting information to the participant (IP ranges and URLs to be whitelisted). SAP All participants leveraging web services connections SAP Load Balancer Root Certificate As mutual authentication happens between participant system and SAP Pharma Network for every inbound web service call, SAP provides the root certificate of the SAP load balancer for the participant to consume. SAP All participants leveraging web services connections and leveraging SOAP WS:RM protocol WSDL SAP provides a WSDL file which contains the message structure, endpoint address and security policy specific to the participant s tenant in the SAP Pharma Network. SAP All participants leveraging web services connections where the payload is opened in SAP Pharma Network (Open Envelope) SAP Message Level Security Keys SAP provides MLS public keys in the form of X.509 certificates. SAP All participants leveraging SFTP connections SFTP Mailbox Public Key SFTP integration includes key based authentication against SAP hosted SFTP mailboxes. Information to Provide During Onboarding 2016 SAP SE or an SAP affiliate company. All rights reserved. 43

44 Provided by To Participant Type Artifact Description SAP All participants leveraging SFTP Public Key for MLS The participant uses this key to encrypt inbound messages to the Pharma Network, and to verify messages received from the Pharma Network. SAP All participants leveraging SFTP SFTP mailbox URLs and usernames SAP provides SFTP mailbox access details to participants Connectivity Elements to Provide to SAP WSDL for Web Services Integration Using Push/Push To use a web services connection to the SAP Pharma Network using a Push/Push communication, you provide SAP with a WSDL file generated from the system that you use to interface with the SAP Pharma Network. This WSDL file contains your system endpoint address, and allows the SAP Pharma Network to connect Connectivity Elements Provided by SAP WSDLs for Web Services Integration If you wish to use a web services connection to the SAP Pharma Network, SAP provides a WSDL file to implement in your backend system. This WSDL file contains your tenant s service endpoint address, and allows you to connect to the SAP Pharma Network IP Ranges and Hostnames To enable you to whitelist SAP Pharma Network s IP ranges and URLs, the SAP Pharma Network Onboarding team provide an IP range and relevant URLs to whitelist SAP SE or an SAP affiliate company. All rights reserved. Information to Provide During Onboarding

45 Endpoints for Web Services Integration The SAP Pharma Network Onboarding team provide you with service endpoints in a WSDL file, or using the XI Adapter for direct consumption in your system if you wish to integrate an ECC to the SAP Pharma Network. 5.2 How Artifacts Relate to Integration Flow Configuration To specify the security related aspects of the message flow, certain settings are required in the relevant integration flows. These security settings are related to the security artifact deployed on the tenant involved. The following table shows how security artifacts and integration flow settings are related to each other. To specify how a message is to be encrypted, you define an Encryptor step in the relevant integration flow. At runtime, this Encryptor step needs to access the required public key to encrypt the message content. The public key must be available in the keystore that is deployed on the tenant. This section summarizes the following requirements for each security option: Security artifact type deployed on the tenant Step or adapter type relevant for the related integration flow design Transport Level Security TLS Key Type Artifact Type to Deploy on Pharma Tenant Integration Flow Step/Adapter Type HTTPS (SSL) Certificate based authentication X.509 certificates Keystore SOAP/IDoc/HTTP adapter. SFTP (SSH) SSH Key and known_hosts Keystore + known_hosts SFTP adapter Message Level Security MLS Key Type Artifact Type to Deploy On Pharma Tenant Integration Flow Step/Adapter Type PKCS#7 X.509 certificates Keystore Signer, Encryptor, Verifier, Decryptor XML Digital Signature Signer, Encryptor, Verifier, Decryptor Information to Provide During Onboarding 2016 SAP SE or an SAP affiliate company. All rights reserved. 45

46 MLS Key Type Artifact Type to Deploy On Pharma Tenant Integration Flow Step/Adapter Type WS Security X.509 certificates. Note: It is SAP best-practice to use separate keys for MLS and TLS. Keystore SOAP adapter/xi Adapter The following figure shows the setup for a tenant in a situation where a keystore containing a public-private key pair is deployed on the tenant as a security artifact SAP SE or an SAP affiliate company. All rights reserved. Information to Provide During Onboarding

47 6 Security Requirements Integration to the SAP Pharma Network is possible for a number of types of backend system, and for generic channels such as SFTP. Backend types include: OER/ATTP direct to Pharma Network using web services OER/ATTP through SAP PI using web services OER/ATTP through SAP PI using SFTP Non SAP Backend using SFTP Non SAP Backend using web services For this reason, the security mechanisms used by a participant can vary. The SAP Pharma Network supports Transport Level Security (TLS) and Message Level Security (MLS). In general, participants using a web services connection (SOAP WS-RM, XI or AS2 HTTPS) require a signed client certificate to mutually authenticate with the SAP Pharma Network Load Balancer. This client certificate must be signed by a SAP trusted Certificate Authority (CA). Note For the current list of SAP Trusted CAs, see Section 7. This list of SAP Trusted CAs is up-to-date at the time of release of this guide. We recommend that you contact your SAP Pharma Network Onboarding team to ensure the list of SAP Trusted CAs is the most recent. In the context of Message Level Security (MLS), SAP recommends that all payloads exchanged between the participant s backend system and the SAP Pharma Network (in a Test and Production onboarding context) are signed and encrypted accordingly. However, you can choose to omit MLS during Test onboarding. An outline of security permutations follows: Backend System Type Interfacing with Pharma Network Using Message Level Security (Signing and Encryption) Transport Level Security SAP ECC web services PKCS#7 PKCS#7 SAP PI web services PKCS#7 PKCS#7 SAP ECC SFTP PKCS#7, SSH, PGP SSH Proprietary web services PKCS#7, PGP PKCS#7 Proprietary SFTP PKCS#7, PGP, SSH SSH Security Requirements 2016 SAP SE or an SAP affiliate company. All rights reserved. 47

48 Note It is feasible that in an SFTP integration scenario, where the sender uses a closed envelope, and where no semantic validation or mapping is expected from the SAP Pharma Network, any MLS standard can be used if the payload can be base64 encoded by the sending system. This scenario requires a pre-shared key exchange between sender and receiver system. 6.1 Onboarding Security Requirements for Test Environment There are a number of security requirements for SAP Pharma Network onboardings to the Test environment. These requirements are described below. Mandatory refers to minimum requirements. Accepted is the baseline that the SAP Pharma Network accepts. SAP Best Practice Recommendation refers to the best practice recommendation from an SAP Pharma Network perspective Web Service Based Security Requirements Mandatory Accepted SAP Best Practice Recommendation Transport Level Security Signed client X.509 certificates for SSL Authentication and Authorization. Signed client X.509 certificates for SSL Authentication and Authorization. Signed client X.509 certificates for SSL Authentication and Authorization. Message Level Security Keys must be compliant with Pharma Network supported key lengths and algorithms as outlined in Section 7. Self-signed message level security keys, with all mandatory requirements observed. Signed message level security keys, signed by a CA of your choosing SAP SE or an SAP affiliate company. All rights reserved. Security Requirements

49 6.1.2 SFTP Based Integration Security Requirements Mandatory Accepted SAP Best Practice Recommendation Transport Level Security N/A Signed client X.509 certificates for SSL Authentication and Authorization. Client of CA Signed keys for SSH Authentication and Authorization. Message Level Security Keys must be compliant with Pharma Network supported key lengths and algorithms as outlined in Section 7. Self-signed message level security keys, that is, PGP, with all mandatory requirements observed. Signed message level security keys, signed by a CA of your choice. 6.2 Security Requirements for Production Environment There are a number of security requirements for SAP Pharma Network B2B onboardings to the Production environment. These requirements are described below. Mandatory refers to minimum requirements. Accepted is the baseline that the SAP Pharma Network accepts. SAP Best Practice Recommendation refers to the best practice recommendation from a SAP Pharma Network perspective Web Service Based Security Requirements Mandatory Accepted SAP Best Practice Recommendation Transport Level Security Signed client X.509 certificates for SSL Authentication and Authorization. Signed client X.509 certificates for SSL Authentication and Authorization. Signed client X.509 certificates for SSL Authentication and Authorization. Message Level Security Keys must be compliant with Pharma Network supported key lengths and algorithms as outlined in Section 7. Self-signed message level security keys, with all mandatory requirements observed. Signed message level security keys, signed by a CA of your choice. Security Requirements 2016 SAP SE or an SAP affiliate company. All rights reserved. 49

50 SFTP Based Integration Security Requirements Mandatory Accepted SAP Best Practice Recommendation Transport Level Security N/A Signed client X.509 certificates for SSL Authentication and Authorization. Client of CA Signed keys for SSH Authentication and Authorization. Message Level Security Keys must be compliant with Pharma Network supported key lengths and algorithms as outlined in Section 7. Self-signed message level security keys, that is, PGP, with all mandatory requirements observed. Signed message level security keys, signed by a CA of your choice. 6.3 How Security Elements Relate to Mail Adapter Use of a mail adapter requires certificates to validate the SSL connection and to encrypt the mail in the case where S/MIME is used. The mail adapter can be used to transmit available reports in the Pharma Network to a receiver. Reports include: Service Availability Reports Configuration Change Reports Activity / Throughput Reports The sender mail adapter enables the tenant to send an encrypted to a receiver system, as shown in the following figure SAP SE or an SAP affiliate company. All rights reserved. Security Requirements

51 The tenant keystore must contain the following certificates: Certificate Receiver server root certificate Tenant client certificate Purpose For SSL Connection, this certificate is required to identify the root CA at the top of the certificate chain that guarantees the integrity of the receiver server certificate. For SSL Connection, this certificate is required to authenticate the tenant when calling the receiver system as client. Security Requirements 2016 SAP SE or an SAP affiliate company. All rights reserved. 51

52 7 Security Certificates and Encryption Standards 7.1 SAP Pharma Network Trusted Certificate Authorities Certificate Authority (CA) Serial no. TC TrustCenter CA TC TrustCenter Class2L1CAX VeriSign Class 3 Secure Server CA G3 6e cc 7a a5 a b8 ce bc f4 e9 52 d4 91 VeriSign Class 3 International Server CA G3 VeriSign Class 3 Public Primary Certification Authority G5 64 1b e8 20 ce f3 2d 4d 2d 95 d6 7e da d1 9e 26 7d e8 bb 4a cd cc 6b 3b 4a Entrust Certification Authority L1C 4c 0e 8c 39 Entrust.net Certification Authority (2048) Serial number of certificate reinstalled on July 20, 2014 (see comment): 3863def8 SAP Passport CA Baltimore CyberTrust Root Cybertrust Public SureServer SV CA Entrust Class 1 Client CA CN = Entrust Root Certification Authority OU = 2006 Entrust, Inc. OU = is incorporated by reference b c 4c 0e 64 6d 45 6b (Thumbprint: b3 1e b1 b7 40 e3 6c da dc 37 d4 4d f5 d f9) O = Entrust, Inc. C = US SAP SE or an SAP affiliate company. All rights reserved. Security Certificates and Encryption Standards

53 7.2 Content Encryption Supported Standards PGP Content Encryption (Supported Algorithms) AES (128, 192, and 256 bit key) Blowfish (128 bit key, 16 rounds) CAST5 (128 bit key, as per [RFC2144]) Blowfish (128 bit key, 16 rounds) DESede (168 bit key) Twofish (256 bit key) PKCS#7 Content Encryption (Supported Algorithms) AES/CBC/PKCS5Padding ARCFOUR/ECB/NoPadding Camellia/CBC/PKCS5Padding DES/CBC/PKCS5Padding DESede/CBC/PKCS5Padding RC2/CBC/PKCS5Padding CAST5/CBC/PKCS5Padding Security Certificates and Encryption Standards 2016 SAP SE or an SAP affiliate company. All rights reserved. 53

54 7.3 Content Signing Supported Standards PGP Content Signing SHA-256 SHA-512 SHA-384 SHA-224 SHA-1 RIPE-MD/160 MD PKCS#7 Content Signing SHA256/RSA SHA512/RSA SHA384/RSA SHA224/RSA SHA/RSA RIPEMD128/RSA RIPEMD160/RSA RIPEMD256/RSA MD5/RSA SAP SE or an SAP affiliate company. All rights reserved. Security Certificates and Encryption Standards

55 8 Glossary Term Authentication Definition The process of confirming someone or something's identity. In the SAP Pharma Network integration scenario, mutual authentication is carried out between the backend system and the SAP Pharma load balancer, and, secondly, authentication after this point against the participant tenant. Both are realized using certificate based authentication (X.509). Certificate Authority (CA) A certificate authority or certification authority (CA) is an entity that issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. In the SAP Pharma Network integration scenario, any certificate must be signed by an SAP-Trusted CA. Related Information Security Certificates and Encryption Standards Client Certificate Cluster Domain Name Service/Server (DNS) Enhanced Key Usage (EKU) Digital certificate used by client systems to make authenticated requests to a remote server. In the SAP Pharma Network integration scenario, a client certificate is required by the participant, with SAP Pharma Network client certificates (those of the load balancer) traded and consumed by the participant. Collective term for customer test and production tenant The way that internet domain names are located and translated into Internet Protocol (IP) addresses. In the SAP Pharma Network integration scenario, the participant's backend system must be able to perform DNS and reverse-dns lookups, and as such, this service must be running on or available to the backend system. Extension which indicates the purpose of the public key contained in the certificate. Defines which applications can be used in conjunction with certain certificates. The purpose of a certificate is defined in its Enhanced Key Usage field. In the participant's Glossary 2016 SAP SE or an SAP affiliate company. All rights reserved. 55

56 Term Definition system, the EKU values must be correctly set, specifically serverauth, and clientauth. Integration flow (I-FLOW) Specifies the flow of messages between two or more participants through the SAP Pharma Network. An integration flow allows you to specify the following: Sender and receivers of the message Endpoints define applied transport protocols Applied measures related to message content signing and encryption Applied mappings Keystore Message level security (MLS) Self-contained collection of certificates and keys that are actively used in the establishment of connectivity to the SAP Pharma Network Summarizes the security settings that can be applied to protect the content of a message. Depending on the chosen standard, message level security can imply digitally signing or verifying, and encrypting and decrypting the content of a message. Onboarding Process of connecting a participant to the SAP Pharma Network. Onboarding covers all tasks necessary to configure the connection and data exchange between a participant system and the SAP Pharma Network. Participant Pretty Good Privacy (PGP) Company or organization that onboards to the SAP Pharma Network A data encryption and decryption computer program that provides cryptographic privacy and authentication for data communication. In the SAP Pharma Network integration scenario, PGP is another encryption standard that is offered for MLS. Public Key Cryptography Standards (Version 7) (PKCS#7) A data encryption and decryption standard that provides cryptographic privacy and authentication for data communication. In the SAP Pharma Network integration scenario, one of the encryption standards offered is PKCS#7, which used extensively by SAP R/3 and PI. Secure Socket Layer (SSL) The standard security technology for establishing an encrypted link between client and server SAP SE or an SAP affiliate company. All rights reserved. Glossary

57 Term Definition In the SAP Pharma Network integration scenario, SSL is used in any web services connection. Service activation Secure Shell (SSH) File Transport Protocol (SFTP) Process when a participant starts collaboration with another participant. On request, SAP activates the connection between the two participants and informs them when the connection is complete. This allows the newly connected participants to carry out message flow testing across the service prior to moving into the production landscape. A participant service activation is carried out in both a test and a production landscape. A protocol that provides file access, file transfer, and file management over any reliable data stream. In the SAP Pharma Network integration scenario, one method of integration between participant backend and the SAP Pharma network is SFTP, which uses SSH. Simple Object Access Protocol (SOAP) Tenant Transport Level Security (TLS) Web Services (WS) XML based protocol for accessing Web Services Represents the resources of the cloud-based integration platform of SAP Pharma Network allocated to a participant. Summarizes settings that can be applied in order to secure the transfer on the communication path between two communication partners. Service offered by an electronic device to another electronic device, communicating with each other over the World Wide Web. In the SAP Pharma Network integration scenario, Web Services are the preferred integration method. Glossary 2016 SAP SE or an SAP affiliate company. All rights reserved. 57

58 9 Support 9.1 SLAs Priority Definition Response Level P1 P2 P3 P4 Very High: The production system is not accessible or a critical business process for mission critical application cannot be completed for multiple users and no workaround is available. It may include issues that materially affect data integrity or breach of security. High: The production system is operational but experiencing a major functional loss that impedes transactions from being completed. The development/test system is not accessible or operational. Medium: The production system is experiencing a minor functional loss that does not significantly impede transactions from being completed. Also includes configurations or change requests that have high business impact. Low: Change or configuration requests and minor problems. Inquiries about product usage and application capabilities. Initial Response: within one hour of case being submitted Ongoing communication: Once every hour Resolution Target: SAP to provide a response within four hours. Response to include either (i) a resolution; (ii) a workaround; or (iii) an action plan. Initial Response: within two hours of case being submitted Ongoing Communication: Once every six hours. Initial Response: within four business hours of case being submitted Ongoing Communication: Once every three business days for non-defect and two weeks for product defect. Initial Response: within one business day of case being submitted Ongoing Communication: Once every week for non-defect and three weeks for product defect. 9.2 BCP Ticket Queues Queue LOD-PHN-INT LOD-PHN-CMO Purpose/When To Use General integration / connectivity queries / support requests for B2B Participants. General CMO Portal queries / support requests SAP SE or an SAP affiliate company. All rights reserved. Support

59 10 Important Disclaimers and Legal Information Coding Samples Any software coding and/or code lines/strings ("Code") included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, unless damages were caused by SAP intentionally or by SAP's gross negligence. Accessibility The information contained in the SAP documentation represents SAP's current view of accessibility criteria as of the date of publication; it is in no way intended to be a binding guideline on how to ensure accessibility of software products. SAP in particular disclaims any liability in relation to this document. This disclaimer, however, does not apply in cases of wilful misconduct or gross negligence of SAP. Furthermore, this document does not result in any direct or indirect contractual obligations of SAP. Gender-Neutral Language As far as possible, SAP documentation is gender neutral. Depending on the context, the reader is addressed directly with "you", or a gender-neutral noun (such as "sales person" or "working days") is used. If when referring to members of both sexes, however, the third-person singular cannot be avoided or a gender-neutral noun does not exist, SAP reserves the right to use the masculine form of the noun and pronoun. This is to ensure that the documentation remains comprehensible. Internet Hyperlinks The SAP documentation may contain hyperlinks to the Internet. These hyperlinks are intended to serve as a hint about where to find related information. SAP does not warrant the availability and correctness of this related information or the ability of this information to serve a particular purpose. SAP shall not be liable for any damages caused by the use of related information unless damages have been caused by SAP's gross negligence or willful misconduct. All links are categorized for transparency (see: Important Disclaimers and Legal Information 2016 SAP SE or an SAP affiliate company. All rights reserved. 59

60 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other countries. All other product and service names mentioned are the trademarks of their respective companies. Please see sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices. Material Number: