Question:
Hi
We have a scenario where an external company want to access our Dev system using an API and RFC's to run a function module - RFC_CALL_TRANSACTION. The problem is, that because we have RFC links between our DEV and Production system with username and password hard-coded, the external company (knowing the system name) can run transactions on our Production system.
How can we restrict the access to just our Dev system?
Any ideas please?
D
Answer:
One of the short falls of RFC scurity, you MUST and SHOULD remove the passwords from the RFC destinations OR make sure the access of the IDs in defined in the RFC destinations only have limited access. There is no reason to have DEV tied to PRD via SM59 definitions. If you remove the passwords then they are challenged to logon tot he target. If the IDs in the RFC definitions only have S_RFC and a few displays then you have no worries. ALso the IDS in the RFC definitions should ALL be CPIC ids alled communication ids) .
Answer:
Thanks John
We have to have the id and password in the rfc connections for many other programs... and it would be difficult to change all those.
So we want to pin down this new user to say, yes, you can get into Dev to run these functions, but you can't rfc from Dev to anywhere else.
Is this feasible?
D
Answer:
Not really, unless you can ensure the access the you give does not have any location where they can enter an RFC destination or look at the contents of table RFCDES
Answer:
If giving the external company a new ID in DEV only and not in the production environment, how is it possible that this external company could redirect their RFC activity to production, regardless of the RFC links between the 2 clients?
Answer:
If giving the external company a new ID in DEV only and not in the production environment, how is it possible that this external company could redirect their RFC activity to production, regardless of the RFC links between the 2 clients?
Depends on the aouthorization they have on the dev system.
RFC_CALL_TRANSACTION is critical.
I would create a Z_* function module which calls RFC_CALL_TRANSACTION, implement additional checks and monitor it's usage.
Even then, don't allow them to start their own Z* transactions.