GENERATE SUBROUTINE POOL Security Issues

[Former Member]

I have a design for a generic rules engine that requires the evaluation of simple ABAP statements at runtime (the statements are stored in a z-table).

I want to use GENERATE SUBROUTINE POOL to wrap these statements in a FORM/ENDFORM which I can then execute at runtime. I also want to use SYNTAX-CHECK FOR on the dynpro that the end-user will use to edit the ABAP statements.

First, I realize the user could put statements into the code that could be damaging so there would have to be a review process in place. But other than that, are there any special security issues that have to be considered to run this statement?

Second, does the end-user need any special security config to run SYNTAX-CHECK FOR? The online help for both of these statements doesn't address any security concerns.

Thanks!

[Former Member]

If the statements are in a Z table, how can the users change them?

Rob

[Former Member]

We would provide a maintenance screen for this z-table.

[Former Member]

Well, I don't like the idea of users creating ABAP statements, but what do your auditors think?

Rob

[Former Member]

The users want the ability to do this so they don't have to contact development. Obviously, there's a trade-off here. If we give it to them then they're responsible and liable (assuming the auditors allow it in the first place). That's not my call. I have to be able to tell them if it's possible from a technical perspective. If the auditors say "no" then it doesn't matter anyway.

[Former Member]

>

> The users want the ability to do this so they don't have to contact development.  Obviously, there's a trade-off here.  If we give it to them then they're responsible and liable (assuming the auditors allow it in the first place).  That's not my call.  I have to be able to tell them if it's possible from a technical perspective.  If the auditors say "no" then it doesn't matter anyway.

Who will raise the transport - the user or a developer?

Rob

[Former Member]

That's a good question. The one or two (max) end-users who would be responsible for putting these rules in would not have access to SE10. Therefore, once they made the changes into dev and unit tested them they would need to contact someone in dev to create the transport.

In our company, when a transport is created it has to go through an approval process. Obviously, a transport containing data from this z-table would require more scrutiny from the CCB. Since devs here don't have access to push transports up the chain, if someone were to want to push destructive code up to production it would require coordination between at least three groups (development, the CCB and then Basis); therefore, it's not very likely it could be done w/o being caught.

[Former Member]

I thought the idea was to save time and reduce effort

Rob

[Former Member]

😄

It's all about perception. The rules-engine approach was actually a recommendation from SAP. Of course, when the user heard that they'd be able to manage the rules themselves they wanted it. Once you dangle that kind of carrot to the user it's almost impossible to take it back. So that leaves us in development trying to figure a way out to give it to them.

Currently the rules are coded into a user-exit. It might be possible to put them in a z-table in such a way that doesn't involve evaluating ABAP code at runtime; however, that approach would be very specific to this application and once they get a taste of this they'll want to use it other places so we were trying to make a generic rules engine.

I concur that it's not ideal but, again, the genie has been loosed from his bottle and getting him back in there without granting wishes is not going to be easy...

[Former Member]

OK - well, you have my security concerns.

Rob

[Former Member]

> Once you dangle that kind of carrot to the user it's almost impossible to take it back.

That is true and this looks like a sub-optimal design to me...

It might also be possible to only make the configurable parts of the rules available to the table maintenance so that they cannot enter their own code, but rather only influence the customizing of how the exit runs.

What I would recommend doing anyway is to add a check for system changability (SE06 and SCC4) to the maintenance view. This way they cannot do development in Production and QA systems...

Cheers,

Julius

[Former Member]

Julius:

Thanks for the great advice, particularly those two t-codes. I hadn't considered that (I'm still somewhat new to SAP).

[former_member194669]

I didn't find any security config if you are using fm EDITOR_SYNTAX_CHECK or RS_SYNTAX_CHECK.

First, I realize the user could put statements into the code that could be damaging so there would have to be a review process in place.  But other than that, are there any special security issues that have to be considered to run this statement?

I have question here. If you allow the user to put commands like

delete from mara ...........

something like that could be an issue isn't it ?

a®

[Former Member]

Obviously, yes. However, a process would have to be put into place to check the statements before they're transported out of dev.