Learn more about SAP Q&A. How to obtain access key for developer? Hi all, I'm a totally new developer, and my company has just installed mySAP. When I try to open ABAP Editor to create a new program, a message appears: 'You are not registered as a developer. Register in SAPNet. Saviynt is a leading provider of Cloud Security and Identity Governance solutions. (Office 365, AWS, Salesforce, Workday) and Enterprise (SAP, Oracle EBS). And the key problems that it was built to solve, and how Saviynt solves these.
There is no risk, only that SAP does not recommend it for operational purposes, as they may apply for use under any circumstances and any change must be screw conveyor according to the corresponding lanscape. For other hand, verifies that within the cost of licensing SAP, are not charging the developer keys you generate. Regards Enviado desde mi BlackBerry? De Claro Argentina -Original Message- From: 'Jeff McDaniel via sap-security' Date: Tue, 27 Apr 2010 20:25:23 To: Subject: sap-security Risk of Developer Key in Production if Production Client is set to 'Not Modifiable' Hi Experts, What is the risk of having a developer key in production if the production client is set to 'Not modifiable' via SCC4 and SE06?
Is there any or does the client settings mitigate any risk of having a developer key in production? Thanks in advance. Jeff - There is absolutely no risk at all - UNTIL somebody changes the client settings! It's one of those things - your control over the system is only as good as you make it. The truly paranoid would not allow the keys in Production. Dave From: Jeff McDaniel via sap-security mailto:[email protected] Sent: Tuesday, April 27, 2010 5:25 PM To: Dave Thornburgh Subject: sap-security Risk of Developer Key in Production if Production Client is set to 'Not Modifiable' Posted by Jeff McDaniel on Apr 27 at 8:33 PM Hi Experts, What is the risk of having a developer key in production if the production client is set to 'Not modifiable' via SCC4 and SE06?
Is there any or does the client settings mitigate any risk of having a developer key in production? Thanks in advance. It's one of those things the auditors would check for.
So you'd have to respond to their finding. All in all, you are better off by removing it in prod. /henrik On 28 April 2010 12:16, Dave Thornburgh via sap-security wrote: Posted by Dave Thornburgh on Apr 27 at 10:17 PM Jeff - There is absolutely no risk at all - UNTIL somebody changes the client settings!
It's one of those things - your control over the system is only as good as you make it. The truly paranoid would not allow the keys in Production. Dave From: Jeff McDaniel via sap-security mailto:[email protected] Sent: Tuesday, April 27, 2010 5:25 PM To: Dave Thornburgh Subject: sap-security Risk of Developer Key in Production if Production Client is set to 'Not Modifiable' Posted by Jeff McDaniel on Apr 27 at 8:33 PM Hi Experts, What is the risk of having a developer key in production if the production client is set to 'Not modifiable' via SCC4 and SE06? Is there any or does the client settings mitigate any risk of having a developer key in production? Thanks in advance.
Jeff, Why will you give developer key access in production system.? If you are giving developer key access in prod then be prepared to give your justification to auditors. Thank you, Sonia On Tue, Apr 27, 2010 at 8:25 PM, Jeff McDaniel via sap-security wrote: Posted by Jeff McDaniel on Apr 27 at 8:33 PM Hi Experts, What is the risk of having a developer key in production if the production client is set to 'Not modifiable' via SCC4 and SE06? Is there any or does the client settings mitigate any risk of having a developer key in production? Thanks in advance.
Hi, I might be misunderstanding the issue here, but in 99% of all SAP environments the DEV and QA system will be assigned to the same installation numbers as the PROD system. The Developer Key is created per installation number, so if the user has the Developer Key for DEV he has also got the Dveleoper Key for PROD. So I think it would be better to make sure the users aren't assigned to the SDEVELOP authorization object, rather than try figuring out how to apply restriction to the Developer Key.
Regards, LEH From: Sonia via sap-security mailto:[email protected] Sent: 13. Mai 2010 23:40 To: Lars-Erik Hallsten Subject: Re: sap-security Risk of Developer Key in Production if Production Client is set to 'Not Modifiable' Posted by Sonia (Sap Bas and Security Design Consultant) on May 13 at 5:37 PM Mark as helpful Jeff, Why will you give developer key access in production system.? If you are giving developer key access in prod then be prepared to give your justification to auditors. Thank you, Sonia On Tue, Apr 27, 2010 at 8:25 PM, Jeff McDaniel via sap-security wrote: Posted by Jeff McDaniel on Apr 27 at 8:33 PM Hi Experts, What is the risk of having a developer key in production if the production client is set to 'Not modifiable' via SCC4 and SE06? Is there any or does the client settings mitigate any risk of having a developer key in production?
Thanks in advance. Hi Agreed with Leh that in most scenarios dev, stg and prd have a common installation number and developer key is based on the installation number. Customization is not possible if system flags for any client is set to 'Not modifiable' via SCC4 and SE06.
Although additonal check on object SDEVELOP should be applied to ensure users do not have debug access in production clients. Anjan Pandey On Fri, May 14, 2010 at 3:23 AM, Lars-Erik Hallsten via sap-security wrote: Posted by Lars-Erik Hallsten(CEO & Senior Consultant) on May 13 at 5:50 PM HiI might be misunderstanding the issue here, but in 99% of all SAP environments the DEV and QA system will be assigned to the same installation numbers as the PROD system. The Developer Key is created per installation number, so if the user has the Developer Key for DEV he has also got the Dveleoper Key for PROD. So I think it would be better to make sure the users aren't assigned to the SDEVELOP authorization object, rather than try figuring out how to apply restriction to the Developer Key. RegardsLEH From: Sonia via sap-security mailto:[email protected] Sent: 13. Mai 2010 23:40 To: Lars-Erik Hallsten Subject: Re: sap-security Risk of Developer Key in Production if Production Client is set to 'Not Modifiable' Posted by Sonia (Sap Bas and Security Design Consultant) on May 13 at 5:37 PM Mark as helpful JeffWhy will you give developer key access in production system.? If you are giving developer key access in prod then be prepared to give your justification to auditors.
Thank youSonia On Tue, Apr 27, 2010 at 8:25 PM, Jeff McDaniel via sap-security [email protected] wrote: Posted by Jeff McDaniel on Apr 27 at 8:33 PM Hi Experts, What is the risk of having a developer key in production if the production client is set to 'Not modifiable' via SCC4 and SE06? Is there any or does the client settings mitigate any risk of having a developer key in production? Thanks in advance. Hi, 1.What is the risk of having a developer key in production if the production client is set to 'Not modifiable' via SCC4 and SE06? No risk her as long as client is set to NOT modifiable via SCC4 / Se06. Risk: When you have external and internal audits,you need to answer them,why 'Production developer key access s gvien' how many users does have it? Since you are giving Production developer key,see to that user are not given Sdevelop (Se38).
Thank you, Sonia On Tue, Apr 27, 2010 at 8:25 PM, Jeff McDaniel via sap-security wrote: Posted by Jeff McDaniel on Apr 27 at 8:33 PM Hi Experts, What is the risk of having a developer key in production if the production client is set to 'Not modifiable' via SCC4 and SE06? Is there any or does the client settings mitigate any risk of having a developer key in production? Thanks in advance. There should be multiple layers of control to prevent development in the production system. The first is to ensure the system is not opened for configuration, and you have controls in place to minimize access if the system ever needs to be temporarily opened.
SCC4 should be highly restricted, and procedures in place if PRD needs to be opened. The second is to not provide development keys in PRD. As others have mentioned, if you share the same installation number between DEV / QA / PRD, you may not be able to prevent this. If you do have the same installation number, you would then need a third layer of making sure that SDEVELOP is not available to any users in PRD (this is good practice anyway). Finally, you can check the DEVACCESS table in PRD. This table should have no entries.
Periodically, this table should be checked to ensure no developer key was used in PRD, and if so, follow up with the person asking what was done.
This blog describes how to setup secure connections to sftp servers in the cloud integration system. It gives a step by step description what needs to be configured where. Furthermore, test options are described for testing sftp connectivity. Setup Secure Connection to sftp Server A typical task in an integration project is to connect sftp servers to the SAP Cloud Integration Tenant, either for sending messages to or for polling messages from the sftp server. Before going into detailed configuration of the communication lets first have a short look at the basics.
Basics of Secure sftp Communication The sftp server can act either as a sender or a receiver of messages. The setup and the detailed configuration procedure differ according to the communication direction that is being set up: whether the sftp server is supposed to provide messages to the integration platform or the other way round. For more detailed information about sftp communication in CPI refer to SAP Documentation chapter. The polling sftp scenario and which security artifacts are involved is described in SAP Documentation chapter. For secure SSH communication a known hosts file has to be deployed in the cloud integration tenant containing the public host key of the sftp server so that the sftp server will be trusted. Furthermore, for public key authentication with the sftp server, a private key has to be maintained in the cloud integration tenant keystore.
Also User/Password can be used instead, in this case user credentials have to be deployed in the cloud integration tenant. Recommended configuration option for secure communication is public key authentication. If you want to configure the connection to an on-premise sftp server via Cloud Connector refer to the blog. Configure Connection in sftp Server and Cloud Integration Tenant Retrieve User and Public Host Key from sftp Server For SSH based communication, the cloud integration tenant needs the host key of the sftp server, which has to be added to the known hosts file and deployed on the cloud integration tenant in the next step. The host key can either be downloaded from sftp server or has to be provided by the administrator of the sftp server. Normally the public key of the sftp server is contained in the.ssh directory with the name idrsa.pub.
To communicate with the sftp server an user account needs to exist on the sftp server. The user name is needed in CPI to connect to the sftp server and has to be provided by the administrator of the sftp server. The user must have sufficient authorization to create/move/delete files on the sftp server. Configurations in Cloud Integration Tenant For SSH based communication in the cloud integration tenant, the public host key of the sftp server provided in previous step is needed in the cloud integration tenant. Furthermore, for using public key authentication towards the sftp server, a private key pair with the alias idrsa or iddsa is required in the cloud integration tenant’s keystore. Maintain and Deploy Known Hosts File You need to add the sftp host key you received in previous step to the known hosts file deployed in your cloud integration tenant.
For this download the file from Manage Security Material view available in the Operations View in Web in section Manage Security. If no knwonhosts file is deployed yet on the tenant you have to create it as described below. Open the file with notepad or some other text editor and add the host key of the sftp server. If no knownhosts file was deployed create it. The file needs to have the name knownhosts and shall contain the host keys for all connected sftp servers in a list.
Each line contains the hostname, the applicable public key algorithm -“ssh-rsa” (for RSA key pairs) or “ssh-dss” (for DSA key pairs) and the public host key encoded using base64. See the following example: ld2345.wdf.sap.corp ssh-rsa AAAAB3NzaC1yc2EAAAo2pOx2ADnZ1WwtjW48= Deploy the knownhosts file in the Manage Security Material view available in the Operations View in Web via the Add - Known Hosts (SSH) action. Browse the knownhosts file and deploy it. Maintain iddsa/idrsa Alias in Keystore As explained above, for public key authentication a private key pair needs to be maintained in the cloud integration tenant keystore. Check for idrsa/iddsa in Keystore In Keystore Monitor available in the Operations View in Web in section Manage Security check, if there is already an entry with the alias idrsa or iddsa available. If so, you may use it and skip the next two steps, continue with download of the public key. Create idrsa/iddsa in Keystore Monitor With the 02-September-2018 update, in the Keystore Monitor you can directly create SSH keys. There is no need anymore to use an external tool for this.
To create the SSH Key open the Keystore Monitor available in the Operations View in Web in section Manage Security. All certificates and private key pairs contained in the tenant keystore are shown. Choose Create - SSH Key to create a key pair for the sftp connectivity.
In the creation dialog select and define the key specific values and define a validity period. The alias is generated automatically based on the selected Key Type:. Key Type RSA - generated alias: idrsa.
Key Type DSA - generated alias: iddsa Select Deploy to create the key. If a key with the respective alias already exists, an error message is given. In this case you may use the existing one for your scenario or use a different Key Type or rename the existing alias. Upon Deploy the idrsa or iddsa alias is generated and the artifact is added to the list of keystore artifacts: Note:. You should not share a private SSH key. Each CPI tenant (e.g.
Test tenant and productive tenant) should have their own SSH key, the same applies to each natural person (e.g. Developer, administrator or consultant) who needs access to the SFTP server. This way access to a specific SFTP mailbox can be granted and revoked to each system and each person separately. You should not use username/password authentication to SFTP servers. Once you have configured multiple systems to access a mailbox via username/password authentication, it becomes very hard to change this password again, because you must change it synchronously on the SFTP server and all involved systems, which are at least two (one writing to the mailbox and one reading from it).
Furthermore, you may need to share this password with administrators and maybe even integration flow developers or external consultants involved in the set-up of the scenario. Once you have shared the password, you cannot make anyone to forget it again, so to remain secure, you would have to change it each time someone leaves the project, which is difficult and error-prone as stated above.
More information about maintaining keys and certificates in Keystore Monitor, about migration of existing keystores into the new monitor and about existing naming conventions can be found in blog ‘. Authorization To maintain keys and certificates in Keystore Monitor your user needs the Group Role AuthGroup.Admin or Single Roles IntegrationOperationServer.read, NodeManager.read and NodeManager.deploysecuritycontent. Download Public Key from Keystore Monitor For public key authentication at the sftp server the public key of the cloud integration tenants private key (idrsa or iddsa) is needed in the sftp server. For this, export the public key of the private idrsa/iddsa key pair in the Keystore Monitor. You can export either the X.509 certificate or the public key in OpenSSH format; choose the format your sftp server supports. This option is available as single line option, select Download Certificate or Download Public OpenSSH Key from the actions Button in the line of the idrsa/iddsa private Key Pair.
Download Public OpenSSH Key will create an.pub file in the download directory. The file contains the public key in openSSH format, which can be used to be put to the sftp server. Download Certificate will create a file with the name.cer in the download directory. This X.509 certificate file can be imported to sftp server, if the sftp server supports the format. If the sftp server needs SSH2 format according to RFC 4716 you need to download the OpenSSH key and transform it to an SSH2 public key with the ssh-keygen tool, which can for example be installed using cygwin on Windows machines. Use following command for the transformation: $ ssh-keygen -e -f idrsa.pub -m RFC4716 idrsa.pubssh2 Authorization To download entries from Keystore Monitor your user needs the Group Role AuthGroup.IntegrationDeveloper or Single Roles IntegrationOperationServer.read and NodeManager.read.
Import Public Key to sftp Server For public key authentication, in the sftp server the public key of the cloud integration tenant’s private key needs to be imported. Provide the downloaded public key to the administrator of the sftp server, so that he can add it there. On an OpenSSH server it’s done via adding it to the authorizedkeys file in the.ssh directory. With this last step the configuration of the communication to the sftp server using public key authentication is completed.
You can now use public key authentication in sftp sender and receiver channels. To test the connectivity, continue as described below.
Connectivity Test After setting up the connection toward the sftp server, the connectivity test feature can be used to test the communication or even to download public keys. SSH Connectivity Test The Connectivity Test is available in Operations View in Web, in section Manage Security Material. Selecting the Connectivity Test tile from Overview Page will open the test tool offering tests for different protocols. To test the communication to the sftp server, the SSH option is to be selected. To test the connection with host key and public key check, select Authentication option Public Key and enter the address of your sftp server, and the user name available in the sftp server and execute the test. The test will give a success message or an error with detailed error information. If there is an error with the SSH connectivity (e.g. Reject HostKey) it is possible to execute the test without the option Check Host Key.
In this case the sftp host key is not checked, but it can be copied via Copy Host Key Button and added to the known hosts file as described in the above chapter. Make sure the fingerprint of the downloaded host key is checked with the administrator of the sftp server.
The public key authentication is checked via the authentication option Public Key. The authentication is done with the idrsa/iddsa key with the user entered in User Name. If there is an authentication error you get an Auth fail error. In this case either the idrsa/iddsa alias is not available in keystore, the public key was not added to the sftp server authorized keys correctly or the user is not valid. If everything is setup correctly you will get a success message with Check Host Key using Public Key Authentication.
Hello, you are right, currently Cloud Integration allows only two aliases for sftp connectivity depending on the key type – iddsa and idrsa. Usually the private key is generated by the server (function generate SSH key), which is in this case the Cloud Integration tenant. And the public certificate for the key is downloaded and passed to all connected sftp servers. With this you can connect multiple sftp servers.
But currently it is not possible to have multiple SSH keys for connecting to the sftp servers. It is on the roadmap, but not for the near future. Best regards, Mandy.