Skip to Content

Why are the people who define allowed transactions in production apparently not very smart?

Why are the people who define allowed transactions in production apparently not very smart?

So often I find that in production, I can use SE80, but SE38 - ooo no. You musn't use that...

Even though I can run from SE80...

5
Show 18
* Please Login or Register to Comment on or Follow discussions.
avatar image
Apr 13 at 03:58 PM
577

I've seen several places that ban SA38 and SE12, but SE38 and SE11 are fine.

2 Share

Same here! :)

0 Share

Restricting authorizations only on transaction id is always a dumb and bad idea.

The same goes for strict authorization on a development system.

2 Share

the auditor who had his first assignment asked the user admin veteran to do this - and since auditors are always right you must not argue with them as this might turn into a red flag in the audit report

And since this pi**ed off the professionals they are no longer telling what security gaps are in a system.

4 Share

Well, even if you restrict TCodes use SE93 and double click on program and perform test on it :)

For example : SE93 --> SU01 --> SAPMSUU0 --> F8

1 Share

Shshsh, don't tell anyone! You'll blow our cover! :)

2 Share

How about SM37 -> details -> program display the program and execute. Depending on what you can use, this is really handy sometimes.

0 Share

SE37 but no SE38 access. Uhm, I can just click a button and change the object type to a report. This is merely a nuisance to me and not a deterrent to anyone with evil intentions.

SA38 access but no SE38. So, you mean I can execute the program but not look what is inside it before I do that?

Also for business users - allow SE17 (without bothering adding any table-level objects) but not SE16. Again, this just makes people less productive, not less potentially dangerous.

I agree with Juergen, this likely comes from the auditors who have no clue. Just like some stupid ABAP stuff comes from the developers who have not learned anything in 20 years but have enough power to make what they do "our standard".

2 Share

I feel the need to put my neck out here as a security person and share some numbers

As someone who prioritises building of support roles so we have access to do our jobs this is what I sift through to figure out what should go where

Now S_TCODE isn't the only entry point authorisations. I'm also trying to adequately restrict S_RFC, S_ICF (if used), S_SERVICE (gateway/fiori mostly), S_START (if enabled for webdynpro). After that it's the next line of defense for S_PROGRAM/S_DEVELOP and a bunch of other S_* objects.

Anyway, when I'm building support roles I like to sift through all transactions in the system (in this one there's 100k+). Some transactions have pretty good describers. Some look interesting so I execute them and make a note of new things I learn. But a lot I have no idea and so I try to look at a SAP standard role to get an idea of what the access is about (could probably look at SE93 object definition as well). Only a tiny portion of those transactions actually sit in a SAP standard role so I get a bit stuck

Next up is on tables for production and the need to protect sensitive data. Sometimes it feels a bit futile (e.g. Basis who have full OS/DB access and here I am trying to protect at application layer). Anyway, quite a few tables to look at S_TABU* object restrictions

I'm also perusing auth objects and fields (TOBJ/AUTHX) as SU24 mappings may not default anything. The older the transaction or the more techy it is the less I've had confidence in it. Amazing how many S_DEVELOP with full asterisk in the default proposal

Total Transactions in TSTC 132,648 Total SAP* or /* Roles (account for delivered content) 4,499 Total AGR_TCODES entries of roles beginning with SAP* or /* (report type is TR for Transaction) 68,599 Total Unique AGR_TCODE Entries where transaction is in a SAP* or /* role 19,663 Total transaction in table TSTC that are not in AGR_TCODES for a SAP* or /* role 132,648 – 19,633 to get the gap Total Auth Objects in TOBJ 3,276 Total Authorisation Fields in AUTHX 2,473 Total Program in TADIR (R3TR/PROG) 299,144 Total Function Modules in TFDIR 445,940 Total Tables in DD02L for transparent/views table categories 151,233

TL;DR - there's lot of possible stuff to give a support user and it's really hard to find the right balance when you're guessing the requirements. Sometimes you're not authorised because we didn't think to include it

I started writing a blog on this topic but needs a bit of polishing. A main crux is that someone who understands technical access requirements and risk needs to define a proper strategy and design for support access.

Sorry for a being a bit serious in Coffee Corner.

Cheers

Colleen

P.s SE38 and those transactions are a challenge. Some organisations want the rule of build a custom transaction for all execute. I used to be in that position but there is so much out there that doesn't have a transaction associated. If you're a developer and building or deploying a program please make sure it gets a transaction and ask someone in security to include it in a role.

P.P.S Agree pointless to deliverable lock down one development transaction and not think through the rest or be inconsistent.

Edited.... My table didn't save....

Total Transactions in TSTC 132,648

Total SAP* or /* Roles (account for delivered content) 4,499

Total AGR_TCODES entries of roles beginning with SAP* or /* (report type is TR for Transaction) 68,599

Total Unique AGR_TCODE Entries where transaction is in a SAP* or /* role 19,663

Total transaction in table TSTC that are not in AGR_TCODES for a SAP* or /* role 132,648 – 19,633

Total Auth Objects in TOBJ 3,276

Total Authorisation Fields in AUTHX 2,473

Total Program in TADIR (R3TR/PROG) 299,144

Total Function Modules in TFDIR 445,940

Total Tables in DD02L for transparent/views table categories 151,233

2 Share

The target of my ire was more the auditors insistance on locking down a transaction code through lack of understanding - not my hard working competent and talented security colleagues.

There are tools available (sorry, not allowed to list 'em) that can record the transaction a user hits while doing his/her job. So you could get a developer and say "go through all the transactions you need" on a test system. The activity is recorded and a resultant draft role is generated.

2 Share

I get that your comment is about auditors but there is still an challenge around providing the access to support staff. Also aware of the tools but unfortunately at sites where they won't use them. Even if they were willing to obtain a license, they then need to get developers and others to put some time aside and actually "go through all the transactions that you need".

I remember making a mistake one time and a PI developer bailed me up in a meeting in front of 20 other people tersely asking "why would you take development access away from a developer in a developer box?!?". I'd made an accidental mapping mistake. We became goods mates out of it but he had lost a good half day at his desk frustrated that he couldn't do his job when a simple call would have resolved it.

Auditors are getting more savvy at access but they are for the most part following checklist and don't understand the actual risk or to look beyond S_TCODE.

0 Share

Well - it's always interesting to me that transactions, security, etc is looked at. But if you play in BASIS at all, you have access at the database level. MMMmmmm...

1 Share

Yep... or the basis team have setup an rfc connection with service user and sap_all to system ho

Audit then exclude system users from scope

0 Share

Just thought of this post today. There is a bunch of programs in DEV that look like some test copies of the same one program. Obviously, the ones in $TMP package are not live but I found some that were in the legit DEV package.

The easiest way to check if these are needed would be to just go to PRD and quickly check in SE38 or SE80 if these exist in PRD. Of course, someone decided that as a developer, I don't need access to SE37/SE38 or SE80. But I have SM37. Only a few smart clicks away from there and bingo, I'm in ABAP Editor. So, what's the point to hide SE38?

0 Share

Wouldn't it be easier to go into version management on dev and do a remote compare to Prod?

1 Share

That's what my teammate said too. :) In this case, I had a "where used" list open in DEV and it just seemed more convenient to have a session with PRD where I could copy-paste the name and get yes or no at once. Could be just a matter of preference.

0 Share

A little part of me died the other day where I had to allow SA38 with full S_PROGRAM access. Support person was upset that I restricted SE38 to display (S_DEVELOP ACTVT 03) so they couldn't execute the program. They soon discovered SA38 with S_PROGRAM SUBMIT would be the same as SE38 with S_DEVELOP ACTVT 16.

Probably should have just have declared defeat and given them ACTVT 16 for S_DEVELOP

I hold hopes that full execute access is just an interim solution until they review security audit logs to identify programs that don't have an assigned transaction and build some customer transactions to add to their support roles.

SA38 is probably now their solution... well (1) got to se38 and it fails (2) get frustrated (3) remember their "SA38 backdoor/workaround" ... (n) profit??

2 Share

Yep, those greedy ABAPers. Give them a finger (display) and they want to bite the whole hand off... :)

0 Share
10 |10000 characters needed characters left characters exceeded