2023-12-7 16:18:50 Author: blogs.sap.com(查看原文) 阅读量:53 收藏
In today’s world of cyber-attacks and data leaks, security and encryption should be an absolute priority for any IT organisation. However, experience shows that this is not always the case. Mechanisms that bring security are still often seen as making work difficult and challenging to implement. The fact that a program was configured years before and there was never a problem is used as an excuse not to make changes. This is a very incorrect approach that can have serious consequences.
In this post, I will cover a topic perhaps quite niche for the SAP Basis administrator – securing connections from external non-SAP programs. An aspect that is often overlooked due to a gap in accountability. On the one hand, this is sometimes seen as outside the Basis scope. On the other hand, programs are sometimes configured by third party vendors not necessarily interested in the security of our system. I will try to show what we, as Basis administrators, can do to make the connection more secure.
In this post I will try to consider what mechanisms we can use to make an external connection secure. Of course, SNC/SSL-based encryption will be the focus as usual, but I will not limit myself to this technical aspect alone. As usual, I will also touch on topics that are on the borderline of responsibilities or even outside the typical scope of Basis, but important for understanding how the various mechanisms work.
I will discuss the topics of encryption, authentication using an SSL certificate, level of trust in a foreign CA, permissions, limiting network traffic. I will base my analysis on example programs from the SAP NetWeaver RFC SDK. I originally wanted to write my own simple program, but as Basis administrators we usually secure existing software and connections, so this is a more representative example.
SAP server side
My test environment is ABAP Platform Trial 1909, based on S/4HANA 1909. The system is not the youngest, nor is it the oldest, but in the field of RFC connection security, not that much has changed over the years. So most of the insights will be valid for both older and younger systems.
The system has already been prepped for SNC and certificate-based authentication. I described this in my previous post “SAP-GUI Single Sign-On based on SSL certificates and SNC“, so I won’t repeat that part.
Client side
For the purpose of presenting the client program, I prepared a completely fresh Debian Linux system version 12. The rfcuser user was also created, in the context of which we will run the program that connects to the SAP server. Of course, you can use another Linux distribution as well, or even Windows, and the results will be similar.
SAP Note 2573790 describes where to get the library and briefly describes the installation process. I assume you can download it yourself from the Software Download Center, and I will describe the simplest installation method in a moment. I get two files, which I decompress in the rfcuser home directory.
rfcuser@sandboxn100:~$ unzip nwrfc750P_12-70002752.zip Archive: nwrfc750P_12-70002752.zip creating: nwrfcsdk/ creating: nwrfcsdk/bin/ inflating: nwrfcsdk/bin/rfcexec inflating: nwrfcsdk/bin/startrfc
[…]
inflating: nwrfcsdk/lib/libsapnwrfc.so inflating: nwrfcsdk/lib/libsapucum.so inflating: SIGNATURE.SMF rfcuser@sandboxn100:~$ unzip nwrfc750P12HF_2-70002752.zip Archive: nwrfc750P12HF_2-70002752.zip inflating: libsapnwrfc.so rfcuser@sandboxn100:~$ mv libsapnwrfc.so nwrfcsdk/lib/
All files are located in nwrfcsdk folder. Next step is adding the folder to LD_LIBRARY_PATH environment variable. I can do this for current session, but to make this permanent, I add this to .profile file located in the user’s home directory.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/nwrfcsdk/lib
I plan to establish a connection from an external program to my SAP system to perform some operations. It is easy to guess that I will need a user on the SAP system side to do this. So I’m creating an RFC user that the external program will use for operations on the system. I give it the top-secret password secure123, just for the purpose of this presentation, to keep things simple.
In addition to filling in basic user data, I set up the type to system or communication. In this case, it doesn’t matter much. I leave the rest of the data default, including the lack of authorizations, because I’ll come back to that in the next step.
Together with the SDK library, we get two sample programs – rfcexec and startrfc. Rfcexec connects to the SAP gateway and waits for incoming commands from the SAP system. I leave it for another occasion for now and will focus on startrfc.
The program connects to SAP and execute one of two function modules, related to EDI or display system information. In fact, I will focus on the last function today. The -i switch is responsible for calling it.
Let’s call the program:
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -i Error: No RFC authorization for function module RFCPING.
Sandbox is my SAP server hostname 00 is SAP instance number. 001 is a productive client.
Error is expected. In general connection is successful, because program reached checking authorization phase.
Indisputably, the principle of least privilege is one of the most important elements of security and an absolute must when it comes to external connections. Keep in mind that a system is only as secure as its weakest component. Even if you secure your SAP system perfectly, an intrusion into a server independent of you that has rights to connect to SAP with a high level of privilege could result in data leakage or even damage to the system. So you should keep the level of RFC user privileges at the minimum level needed to operate. In fact, this should obviously apply to all users. However, for technical users, this rule is more often ignored for some reason. Do we trust programs more than people?
That’s why I didn’t give the RFCUSER any authorization at the beginning, and now I will build it from scratch. I check what the SU53 transaction reports for this user by selecting Authorization Values / Other User from the menu.
Apparently, the system first checked whether the user had access to the RFCPING function module. Since access was not explicitly granted, so the permissions for the entire SYST function group were also checked. Since I am very strict about permissions, I will build a role with minimal privileges in the PFCG tranaction.
I added this role to RFCUSER and repeated the connection test.
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -i SAP System ID: A4H SAP System Number: 00 Partner Host: vhcala4hci Own Host: sandboxn100 Partner System Release: 754 Partner Kernel Release: 777 Own Release: 753 Partner Codepage: 4103 Own Codepage: 4103 User: RFCUSER Client: 001 Language: E
This time the connection is fully successful and I get system information. Authorization is sufficient.
At this point it is worth saying a few words about how my system is configured. This is, in fact, already described in my previous post, but it doesn’t do any harm to remind you of the basic information. The main certificate authority (OU=Security) signed the certificates of intermediate authorities – for servers (OU=Servers) and for users (OU=Users). The SAP server certificate was issued by the first one.
It’s clear that the simplest solution would be to issue a certificate by an existing certification authority, but that would simplify our considerations a bit too much. Instead, I will assume that the certificate was issued by a completely independent group of certification authorities. So I will add three new to the existing ones, marked in blue in the diagram.
I won’t focus on details, because you can go through this proces in my previous post, but let’s go to the process of CAs creation and issuing RFCUSER’s certificate. In practice, SAP administrators are usually not responsible for this part, so if you are not interested in issuing certificates, you can skip without hesitation to the next chapter.
Root CA key creation:
openssl genrsa -out AnotherRootCA/anotherca.key.pem 4096
Certificate generation:
openssl req -x509 -sha256 -new -nodes -key AnotherRootCA/anotherca.key.pem -days 3650 -out AnotherRootCA/anotherca.cert.pem You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:PL State or Province Name (full name) [Some-State]:kuj-pom Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany Organizational Unit Name (eg, section) []:Trustworthy Common Name (e.g. server FQDN or YOUR name) []:Another Root CA Email Address []:
Intermediate CA key:
openssl genrsa -out intermediateAppsCA/interApps.key.pem 4096
Certificate signing request:
openssl req -key intermediateAppsCA/interApps.key.pem -new -sha256 -out intermediateAppsCA/interApps.csr.pem You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:PL State or Province Name (full name) [Some-State]:kuj-pom Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany Organizational Unit Name (eg, section) []:Apps Common Name (e.g. server FQDN or YOUR name) []:Intermediate Apps CA Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:******* An optional company name []:
Certificate signature by the new root CA:
openssl x509 -req -in intermediateAppsCA/interApps.csr.pem -days 3650 -CA AnotherRootCA/anotherca.cert.pem -CAkey AnotherRootCA/anotherca.key.pem -CAcreateserial -out intermediateAppsCA/interApps.cert.pem Certificate request self-signature ok subject=C = PL, ST = kuj-pom, O = AnotherCompany, OU = Apps, CN = Intermediate Apps CA
RFCUSER key creation:
openssl genrsa -out intermediateAppsCA/rfcuser.key.pem 4096
Certificate signing request:
openssl req -key intermediateAppsCA/rfcuser.key.pem -new -sha256 -out intermediateAppsCA/rfcuser.csr.pem You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:PL State or Province Name (full name) [Some-State]:kuj-pom Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []:RFCUSER Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:******** An optional company name []:
Client.cnf for client certificates:
nsCertType = client extendedKeyUsage = clientAuth
Certificate signing:
openssl x509 -req -days 365 -in intermediateAppsCA/rfcuser.csr.pem -sha256 -CA intermediateAppsCA/interApps.cert.pem -CAkey intermediateAppsCA/interApps.key.pem -CAcreateserial -out intermediateAppsCA/rfcuser.crt.pem -extfile intermediateAppsCA/client.cnf Certificate request self-signature ok subject=C = PL, ST = kuj-pom, O = AnotherCompany, CN = RFCUSER
Export certificate to PKCS12 format:
openssl pkcs12 -export -inkey intermediateAppsCA/rfcuser.key.pem -in intermediateAppsCA/rfcuser.crt.pem -certfile AnotherRootCA/anotherca.cert.pem -certfile intermediateAppsCA/interApps.cert.pem -out rfcuser.p12 Enter Export Password: Verifying - Enter Export Password: exportpassword123
As a result I got several keys and certificates, including the most important rfcuser.p12 file, which contains user’s private key and certificate with the trust chain. The file is protected with exportpassword123 password. In real life scenarion this file you’ll receive from your certification team.
Ok, I know that forcing encrypted connections is not necessary for my connection to be encrypted. However, I will do it to show if the encryption works or not. Nevertheless, if you are ready to disable unsafe connections, I highly recommend making it permanent. In my case, the snc/only_encrypted_rfc parameter is sufficient, but you might consider setting a few others as well, such as snc/accept_insecure_cpic, snc/accept_insecure_gui, snc/accept_insecure_rfc, snc/only_encrypted_gui.
I can set the parameter to 1, which enforces encryprion for non-ABAP RFC connections. Higher levels enforces encryption for ABAP and intenal connections.
snc/only_encrypted_rfc = 1
Now the call should be rejected by the system.
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -t 3 -i Error: Unencrypted communication is rejected by this system
It is no longer possible to establish an unencrypted connection.
To enable RFC connection encryption, it is necessary to install a cryptographic library. On SAP systems it is included along with the kernel, while here it must be installed separately. I go to the SAP Marketplace to see what the latest version is and download it. In addition, I need to get the SAPCAR program to decompress the archive. So in the end I choose 2 files and save them in a new cryptolib folder.
SAPCRYPTOLIBP_8553-20011697.SAR SAPCAR_1200-70007716.EXE
It’s time to unpack the library:
rfcuser@sandboxn100:~/cryptolib$ ./SAPCAR_1200-70007716.EXE -xf SAPCRYPTOLIBP_8553-20011697.SAR SAPCAR: processing archive SAPCRYPTOLIBP_8553-20011697.SAR (version 2.01) SAPCAR: 6 file(s) extracted
SAPCAR and the archive can be removed after extraction. Let’s also start sapgenpse component to check if everything is fine.
rfcuser@sandboxn100:~/cryptolib$ ./sapgenpse | tail -10 Versions: SAPGENPSE 8.5.53 (Sep 22 2023) CommonCryptoLib 8.5.53 (Sep 22 2023) [AES-NI,CLMUL,SSE3,SSSE3] Build change list: 248172 USER="rfcuser" Environment variable $SECUDIR is not defined! Fallback selection of SECUDIR through HOME: "/home/rfcuser/sec"
It would be good to set SECUDIR variable explicitly and add cryptolib folder to LD_LIBRARY_PATH variable. Let’s edit .profile of the user.
rfcuser@sandboxn100:~$ cat .profile export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/nwrfcsdk/lib:~/secudir export SECUDIR=/home/rfcuser/sec
In the previous sections, I generated an SSL certificate for the RFCUSER. It was saved in the file rfcuser.p12. Even if you don’t generate the certificates yourself, you will probably get a ready one from the certification authority in this format. In the SAP world we rather operate on PSE repositories, so with the help of sapgenpse I will convert PKCS#12 to PSE. I will perform all operations in the rfcuser user sec folder.
I prepared files, including certification authorities’ certificates:
rfcuser@sandboxn100:~/sec$ ls -l total 24 -rw-r--r-- 1 rfcuser rfcuser 2033 Nov 30 18:28 anotherca.cert.pem -rw-r--r-- 1 rfcuser rfcuser 1911 Nov 30 18:29 interApps.cert.pem -rw------- 1 rfcuser rfcuser 5875 Nov 30 18:28 rfcuser.p12
Let’s import the p12 file into new repository and protect it with MyVerySecretPIN_1 secret PIN.
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse import_p12 -x MyVerySecretPIN_1 -p SAPSNCS.pse -r anotherca.cert.pem -r interApps.cert.pem rfcuser.p12 Please enter PKCS#12 encryption password: ***************** Found key 'INDEX=0,SIG=YES,ENC=YES,MD5-FINGERPRINT=60A1 B7F2 4F30 C198 9457 D2C3 5FA4 7F8E,KEYID=57F11B35BBC963B83B3B65F2666726003D11A46F' PSE "/home/rfcuser/sec/SAPSNCS.pse" was written
The PIN we can encrypt in cred_v2 file, which is kind of passwords repository. Later this can be used by tools to access the PSE file. I also update file permissions to more strict.
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse seclogin -x MyVerySecretPIN_1 -p SAPSNCS.pse running seclogin with USER="rfcuser" Added SSO-credentials for PSE "/home/rfcuser/sec/SAPSNCS.pse" rfcuser@sandboxn100:~/sec$ chmod go-rwx cred_v2
Finally I have below files with PSE and cred_v2.
rfcuser@sandboxn100:~/sec$ ls -l total 28 -rw-r--r-- 1 rfcuser rfcuser 2033 Nov 30 18:28 anotherca.cert.pem -rw------- 1 rfcuser rfcuser 114 Nov 30 18:37 cred_v2 -rw-r--r-- 1 rfcuser rfcuser 1911 Nov 30 18:29 interApps.cert.pem -rw------- 1 rfcuser rfcuser 5875 Nov 30 18:28 rfcuser.p12 -rw------- 1 rfcuser rfcuser 5111 Nov 30 18:36 SAPSNCS.pse
Let’s check what was saved in the PSE. I can see main certificate, signing CA and validity dates.
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse get_my_name -p SAPSNCS.pse SSO for USER "rfcuser" with PSE file "/home/rfcuser/sec/SAPSNCS.pse" Subject : CN=RFCUSER, O=AnotherCompany, SP=kuj-pom, C=PL Issuer : CN=Intermediate Apps CA, OU=Apps, O=AnotherCompany, SP=kuj-pom, C=PL Serialno : 72:7B:01:77:64:B6:60:0B:31:D7:6C:60:66:0A:B2:7E:AB:FD:77:B1 KeyInfo : RSA, 4096-bit Validity - NotBefore: Thu Nov 30 17:54:25 2023 (231130165425Z) NotAfter : Fri Nov 29 17:54:25 2024 (241129165425Z) KeyUsage : none ExtKeyUsage : ClientAuthentication SubjectAltName : none
I can also confirm, that the trust list of the PSE is empty.
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -p SAPSNCS.pse -l maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse" PKList is empty. Empty trusted list.
The next step is to prepare the RFCUSER user for SSO authentication. To do this, I update the SNC name field in the SNC tab in the SU01 transaction. At the same time, I can disable the option of logging in with a password.
The sapnwrfc.ini file allows to configure connection parameters for RFC calls made with the SDK library. You can define parameters there, such as the details of the system you are connecting to, the method of authentication, or encryption. Of course, you can specify a username and password there, but I will be configuring a certificate-based SSO. So I create the sapnwrfc.ini file in the same directory as the startrfc program:
rfcuser@sandboxn100:~/nwrfcsdk/bin$ cat sapnwrfc.ini DEST=a4htest SNC_LIB=/home/rfcuser/cryptolib/libsapcrypto.so SNC_MYNAME=p:CN=RFCUSER, O=AnotherCompany, SP=kuj-pom, C=PL SNC_PARTNERNAME=p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL SNC_QOP=9
For readability, the file contains a minimum set of parameters. DEST defines the name of the connection, which must be referred to by the program making the connection. SNC_LIB defines which cryptographic library to use. SNC_MYNAME specifies the SNC name of the client. SNC_PARTNERNAME gives the SNC name of the SAP server to which we are connecting. SNC_QOP defines the scope of the SNC, where 9 defines the maximum available security level.
I can return to startrfc program and update required parameters. The most important one is -D, which defines connection name, consistent with sapnwrfc.ini definition.
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i
You might notice that the parameters responsible for the username, password and client number have been removed. They are not required if the SNC string is unique, that is, only one user on one client in a given system has this specific SNC name assigned to it.
The connection name is essential when you are securing a application that you are not the author of. The most important thing is to find in the documentation or configuration options how to determine this parameter or how to define it. Once you know this you will most likely be able to enable secure connection and encryption, even if the documentation from the vendor does not mention anything about such feature.
Ok, let’s start the program to see what else is missing:
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i [Thr 139683030722496] Thu Nov 30 18:50:59:304 2023 [Thr 139683030722496] *** ERROR => SncPEstablishContext() failed for target='p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL' [/bas/753_R 3638] Error: LOCATION CPIC (TCP/IP) with Unicode ERROR GSS-API(maj): Miscellaneous failure GSS-API(min): A2210223:Server does not trust my certificate path target="p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL" TIME Thu Nov 30 18:50:59 2023 RELEASE 753 COMPONENT SNC (Secure Network Communication) VERSION 6 RC -4 MODULE /bas/753_REL/src/krn/snc/sncxxall.c LINE 3604 DETAIL SncPEstablishContext SYSTEM CALL gss_i
The error message is clear – SAP server does not trust my certificate chain. What does it mean?
The situation is as follows – the client approaches the server with a certificate, which perhaps even matches the SNC name of some user in the system. But after all, such certificate can be issued by anyone and any subject can be defined. Therefore, it is very important that the certificate is known and accepted by the server. This can be a trust relationship defined directly – by adding this particular certificate to the list. However, it can also be defined at a higher level – by trusting the certification authority.
It is the administrator’s decision, or more often security policies, at which level we establish the trust relationship. It is very convenient to add a specific CA to the trusted list and this is often the right way to go. However, be aware that this also has consequences. The organisation that issues the certificates receives the authority to authenticate users on our system.
When we are unable to trust the certificate authority, we are required to add the leaf certificate to the list. This usually brings with it quite an inconvenience – the need to renew each certificate as it approaches its expiration date. This requires coordination with the client and, with a larger number of certificates, can be very inconvenient, especially as end certificates usually have an expiry date of one year.
As I have full control over my certificate authorities, so I add Another Root CA to my trusted list in transaction STRUST.
Let’s retry the connection.
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i [Thr 139834091542464] Thu Nov 30 18:58:31:277 2023 [Thr 139834091542464] *** ERROR => SncPEstablishContext() failed for target='p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL' [/bas/753_R 3638] Error: LOCATION CPIC (TCP/IP) with Unicode ERROR GSS-API(maj): Miscellaneous failure GSS-API(min): A2200223:Peer certificate path not trusted target="p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL" TIME Thu Nov 30 18:58:31 2023 RELEASE 753 COMPONENT SNC (Secure Network Communication) VERSION 6 RC -4 MODULE /bas/753_REL/src/krn/snc/sncxxall.c LINE 3604 DETAIL SncPEstablishContext SYSTEM CALL gss_init_sec_context
There is still an error, but different one. This is also related to trust, but in opposite direction. Now client doesn’t trust server. I need to add SAP system certificate or better it’s CA to the client’s trusted list. Let’s go to SECUDIR and add it to PSE.
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -a ca.cert.pem Please enter PSE PIN/Passphrase: ***************** maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse" ---------------------------------------------------------------------------- Subject : OU=Security, O=MyCompany, SP=kuj-pom, C=PL PKList updated (1 entries total, 1 newly added) rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -a interServers.cert.pem Please enter PSE PIN/Passphrase: ***************** maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse" ---------------------------------------------------------------------------- Subject : OU=Servers, O=MyCompany, SP=kuj-pom, C=PL PKList updated (2 entries total, 1 newly added)
I have to know PSE password to modify it.
You can always your trusted list with below command:
rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -l
Now I can test the connection once more.
rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i SAP System ID: A4H SAP System Number: 00 Partner Host: vhcala4hci Own Host: sandboxn100 Partner System Release: 754 Partner Kernel Release: 777 Own Release: 753 Partner Codepage: 4103 Own Codepage: 4103 User: RFCUSER Client: 001 Language: E
Success. Connection is possible with SSL based authentication. Encryption is obviously enabled.
When we consider how to secure RFC connections, it is impossible to ignore the question of the firewall. It is obvious that also at the network level, we should only allow traffic from addresses that are allowed to communicate with our server. One question to ask is which ports are needed. There are two ports that are used by the Gateway, which is responsible for RFC communication – 33<NN>/tcp and 48<NN>/tcp. NN is instance number, in my case 00. 3300/tcp is used for unencrypted communication, while 4800/tcp is the secure gateway, where communication is encrypted. In my case, after configuring a secure connection, only 4800/tcp is needed.
However, there is one more port to be considered. It is opened by the message server, which is part of the ASCS instance, that in my case is number 01. So I would also consider opening port 3601/tcp on the firewall to allow load balancing using login groups.
The final option I wanted to recommend to make RFC connections more secure is Unified Connectivity (UCON). This is a mechanism that provides the ability to define a list of allowed remote function modules. This is related to the idea of reducing the attack surface. It is clear that systems only use a very small proportion of functional modules. As the software may contain security vulnerabilities and somewhere in the system someone may have set too broad permissions, it is worth implementing protection at a higher level. UCON introduces an extra layer of protection – even before the user’s permissions are checked, it is verified whether the call is on the allowed list. However, UCON is a rather broad topic for a separate article.
RFC connections from external non-ABAP programmes can be secured on very many levels. Security should be a priority these days and unencrypted connections forbidden by any security policy. Although we often have less control over external programs, as you can see, quite a lot can be done in this area too.
如有侵权请联系:admin#unsafe.sh