Z and Y transactions

[Former Member]

Hi, my boss has asked me to come up with a method of how to keep tabs on new Z**** transaction codes and new Y******** transaction codes. This is required for Audit purposes.i need a dynamic method of updating this information timeously. how can this be done?

[morten_nielsen]

Hi Benton

If you need to keep track off then, then try to have a look at the table tstc and tstct (with SE16).

However, from a security point of view, you should be aware that this isn't sufficient. Functionality can be created and executed from a variety of other object with out assigning a transaction code(e.g. report, webdynpros, BSP etc)

Regards

Morten Nielsen

[Former Member]

Morten

but you as security administrator are in the lead to Let people not being able to bypass T_CODE assignment:

F.i. do not give access to SA/SE38 so users can not start programm's directly.

and do not create roles with a wildcard or range in the S_TCODE object.

That is forcing developers to go through the security admin for adding T_Codes to roles before users can access program's.

Tip on the latter be very carefull not to give to wide access in Dev and QA systems, thus forcing developers to come to you for access for testing already not when the program is already in Prod.

[morten_nielsen]

Hi Auke

I Agree with you on the point of assigning t_codes to reports etc... but still with the correct access you will be able to execute reports without access to se38, se80 (or any other t_code at all).

And a lot of the new netweaver functionality is build in away, so that t-codes doesn't make sense, e.g have a look at this https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/bf20e84f-0901-0010-fe9e-91d... . In this example SE16 is recreated in webdynpro and called from a URL

Regards

Morten

[Former Member]

Hi Morten,

Thanks for the interesting article! I guess we can unlock SE16N now...

Cheers,

Julius

[Former Member]

I see your point, Morten.

But i would say that for every development there should be a security impact paragraph written in the design document, and these risk should be tested and these tests should be documented as well!! So we should know what to give to users and what the risks are.

I am aware of the fact that not all companies have their development controlled by clear and complete documentation, but who wants to be responisble for the security in such a messy environment.

Do not seek the answer to these problems in technical solutions, but in proper procedures and responsibilites

[WolfgangJanzen]

See page 18 of <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/bf20e84f-0901-0010-fe9e-91d100013a59">the quoted document</a>: an AUTHORITY-CHECK on object S_TABU_DIS is performed.

<u>Notice</u>: ABAP transactions are not the only "entry point" to an NWAS ABAP system; RFCs/BAPIs and ICF services are additional start points - which are subject of <b>start authorization checks</b> (-> S_RFC resp. S_ICF). Every application (here: generic table browser) should perform additional authorization checks in order to allow a more fine granular control on permissible actions.

Regards, Wolfgang

[Former Member]

I'm with Auke on this one. Without robust, up-to-date (or even <a href="http://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/c2992ca9-0e01-0010-adb1-b7629adb623c">ahead-of-date</a>... <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/4fbafc9e-0e01-0010-dea9-9d23d1b269fb">2</a>... <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f2dac69e-0e01-0010-e2b6-81c1e8e5ce50">3</a> ) developer standards, guidelines, code reviews and change procedures to follow, the system security will deteriorate.

Alone the fact that it is not clear for developers how and which authority-check objects to use or convensions to stick to, will create an inconsistent implementation, gaps in the security and maintenance overhead in the long run (e.g. maintaining an IF SY-UNAME <> ... concept).

However, setting up the technical solutions correctly is equally important. Particularly so if the organizational and procedural hurdle is high.

Cheers, Julius

[WolfgangJanzen]

Yes, I fully agree.

And actually the example above demonstrates an incomplete check (S_TABU_CLI is not checked). Usually such complex checks should be encapsulated by an ABAP function module (e.g. VIEW_AUTHORITY_CHECK or AUTHORITY_CHECK_TCODE, to mention another common example).

That's why such checks should be performed at the inner-most point (beyond the API boundary). Then all callers will experience the same behavior regarding functionality and authorization requirements.

Unfortenately, not in all cases existing APIs are reused - but sometimes re-invented (with slightly different functionality - and different authorization checks).

Cheers, Wolfgang

[Former Member]

PS: I am just a hobby abaper, so please correct me...

Cheers,

Julius

(Oops...Self-corrected incorrect statement).

Message was edited by:

Julius Bussche

[WolfgangJanzen]

Hi Julius,

unfortenately you seem to have removed some statements from your posting. In the original version (which was sent to me by mail on subscription) you've made a comment on S_TABU_CLI and on developers who "wanted to only permit <b>maintenance of client dependent entries in client independent tables</b>".

Well, that is simply <b>not possible</b>.

A client-independent table is entirely different from a client-dependent one.

The first one does <u>not</u> have a (key) field of type CLIENT while the latter one does have one. Changes to client-independent tables do effect all clients of that system - for which an additional authorization check is appropriete.

Example for client-independent table: RFCDES (containing all RFC destinations).

Cheers, Wolfgang

PS: I'm also only a hobby ABAPer. I'm using C as programming language.

[Former Member]

Hi Wolfgang,

Yes, that is what I realized (albeit too late).

I was thinking (not enough though) of T000 when commenting about the WHERE ... NE MANDT, but forgot that T000 is <i>the</i> client independent table and that it would obviously not work for the majority of the others where MANDT is not available.

So I agree that an S_TABU_CLI check for the table to be accessed is missing. Well spotted (demonstrating the importance of a good code review)!

Cheers,

Julius

[Former Member]

Here i come back with the procedures.

If these are correct. any development, including OWN ABAP's, will pass the security team BEFORE being actually done.

Solution for ABAP's the security team will add mandatory security checks to be incorporated in the ABAP code. Although it is actually the task of the Functional designer to do that!!!

As i see it there is a lot of education still to do!!!

[WolfgangJanzen]

Well, but very soon the "security team" will become the bottleneck - and will face severe pressure to approve "urgently required functionality" ...

No, I strongly believe that "security" is just another quality aspect of good software products - comparable to other aspects such as "performance", "usability", "robustness", "scalability" and (last but not least) "supportability".

Sooner or later "functionality" becomes less important than all those "soft skills" I've just mentioned above. But (except "usability" maybe) they are not so apparent to the eye - at the moment of purchase decisions. That's a pitty - but also a fact.

Cheers, Wolfgang