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...

* Please Login or Register to Comment on or Follow discussions.

18 Comments

  • Apr 15 at 06:23 AM

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

  • Apr 16 at 01:35 PM

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

    The same goes for strict authorization on a development system.

  • Apr 16 at 02:15 PM

    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.

  • Apr 19 at 03:59 PM

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

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

    • Apr 20 at 06:07 PM

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

    • Apr 24 at 06:12 PM

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

  • Apr 20 at 06:04 PM

    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".

  • Apr 23 at 11:18 AM

    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

    • Apr 23 at 07:02 PM

      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.

      • Apr 24 at 12:00 PM

        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.

  • Apr 24 at 06:15 PM

    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...

    • Apr 24 at 11:44 PM

      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

  • May 07 at 05:13 PM

    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?

    • May 08 at 07:27 AM

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

      • May 08 at 03:35 PM

        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.

    • May 09 at 11:01 AM

      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??

      • May 09 at 03:58 PM

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

  • Add comment
    10|10000 characters needed characters exceeded