Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Ability to filter gateway logging and simulate "go lives"...

Former Member
0 Kudos

Dear gurus,

For those of you have attempted to maintain secinfo and reginfo files (and now any proxy and message servicer ACLs) the subject title should be enough said.

The local and internal contexts account for 99% of the starting and registering of external programs. These create a huge amount of racket in the logging and in the case of secinfo dont give you the USER-HOST unless you activate additional filters, which effectively doubles the trace logging file size.

I would like to create a "functionality wishlist" in the wikis for two new features, but first wanted to test the ideas here and see whether there is agreement:

1) gw/ignore_info parameter

A file which allows certain entries not to be logged, particularly the "local" and "internal" HOST and USER-HOST entries which are anyway contained by the authorization conceot for transactions such as STMS and SM69 and SM37 (as well as some function modules which respect the application concepts, such as SXPG FMs).

This would mean one can only log (and have to read...) exceptions which are truely started or registered remotely!

2) gw/simulate_info parameter

A file which can represent the secinfo and reginfo files to show what would have happened if the real files were active.

The problem is that one cannot realistically test and let alone transport the files from DEV to QAS to PROD. You have to take risks when going live in PROD as the partners and jobs and various other dependencies (call backs) only happen there. Customers are very scraed of such Go-Lives regardless of the support offered (I sometimes spend the night clicking on a refresh button...). The ability to simulate the affect of an active secinfo and reginfo would be very cool.

Any support? If I have a few "thumbs up" then I will create a wiki for it after some discussion about whether a better approach is possible.

For sure something needs to be done, as if client systems using outbound gateway registrations fail to accept critical business data which then creates inconsistencies (customers hate that, even the thought of it!) then there is most likely no second chance to secure the gateway or RFC in general again.

Aye or nay or better suggestion?

Cheers,

Julius

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Ayay Captain!

Great idea!

There is a lot of customer-friendlyness improvement to be made in that area...

Just another thing, little bit related. What about a more 'automated' was of going through the logfiles and finding the unique entries and adding them in a firewall-kind-off way by pressing ACCEPT of DENY buttons...

16 REPLIES 16

Former Member
0 Kudos

Aye from me, especially as implementing #1 should make the requirement for #2 virtually redundant.

0 Kudos

Thanks guys!

@ Alex: the ability to simulate is IMO also needed, as the exception log does not always clearly tell you the USER-HOST, you do not know which "permit" entry in the secinfo or reginfo it reached to be accepted and any mistake in the format of a line means that the whole line is ignored. The ability to simulate will mean that you can test it in realistic (productive) environments without actually causing problems or experimenting with the entries which do and which do not permit access.

Cheers and thanks again,

Julius

0 Kudos

That's a fair point, retrofitting gateway logging is an "interesting" task.

I have a client recently do it as part of a greenfield implementation and it was a much easier process (a bit like role design).

martin_voros
Active Contributor
0 Kudos

Hi,

number 2 reminds me SELinux. You can enforce rules or just log violations of rules. Just logging violations helps you to define proper rules and then just switch to enforce mode. I vote for both features.

Cheers

Former Member
0 Kudos

Ayay Captain!

Great idea!

There is a lot of customer-friendlyness improvement to be made in that area...

Just another thing, little bit related. What about a more 'automated' was of going through the logfiles and finding the unique entries and adding them in a firewall-kind-off way by pressing ACCEPT of DENY buttons...

0 Kudos

Thanks for the support!

There is already an option to automatically generate the secinfo and reginfo files, but it uses the outbound type T RFC connections which may or may not register themselves back again and might also possibly be "dead wood" anyway.

Something like "Show unique entries only once" is perhaps what you are looking for. That would also be very easy in ABAP.

I will add it as a third wish to the wiki when we have enough support - I think we are almost there already...

Cheers,

Julius

0 Kudos

> I will add it as a third wish to the wiki when we have enough support - I think we are almost there already...

Should I create some fake accounts and vote for this idea?

0 Kudos

Good idea! Just don't get caught..

After a few days I will move it to the "basis forum" (Netweaver Administrator). In my experiences these tasks normally land with basis because security is in reality mostly PFCG it seems. The basis folks have also been pestered about this by the Earlywatch reports for some time now so some of them might actually have been through the experience a few times.

Cheers,

Julius

PS: I see that SAP have started maintaining the wikis... good sign --> http://wiki.sdn.sap.com/wiki/display/Security/Gatewaysecuritysettings-extrainformationregardingSAPnote+1444282

Edited by: Julius Bussche on Nov 23, 2011 10:43 PM

0 Kudos

> basis because security is in reality mostly PFCG it seems.

I agree, and that is too bad! There are so many flaws in DB's, network, Frontends, OS and application layer that can potentially be very dangerous to your SAP infrastructure... And yet almost anyone calling himself SAP Security professional is building roles and profiles (Sorry if I hurt some people, that is not my intention, it's just what I see happening out there in the field). Yes, that is very important, but what about 'the other half" of SAP Security?

Ok, so far for my personal frustration...

I'll try to do something about it by raising awareness on the next Sap Inside Track NL:

http://wiki.sdn.sap.com/wiki/display/events/SAPInsideTrack2011Netherlands

Thanks Julius for looking beyond!

Edited by: Joris van de Vis on Nov 24, 2011 12:04 PM

0 Kudos

And yet almost anyone calling himself SAP Security professional is building roles and profiles (Sorry if I hurt some people, that is not my intention, it's just what I see happening out there in the field). Yes, that is very important, but what about 'the other half" of SAP Security?

There is no need to apologise! Talking about it can only raise the profile of the topic. I would go so far as to say that people should not call themselves a security professional if they only know roles and users.

There is a big skills gap in the SAP security industry and the more complex the application landscape gets, the bigger the gap will get.

Cheers

0 Kudos

What irritates me most is assumption security = SoD. While I am ranting another one is when you define your roles you are done with security for next 5 years and there is no need for budget. Who cares about patch Tuesdays and many other things.

Cheers

0 Kudos

What irritates me most is assumption security = SoD.

I try my best to move those to the GRC forum without delays... You can however also control many non-application specific parts of a SAP system from ABAP transactions and these are controlled by ABAP authorizations. ABAP is very powerful... A few examples are SE14, SM69 and (revelant to this example) also SMGW to transfer the control to the application layer by forcing it (local context of the USER-HOST). So authorizations are also important and omni-present (execpt for the config tool on the Java Stack...

While I am ranting another one is when you define your roles you are done with security for next 5 years and there is no need for budget. Who cares about patch Tuesdays and many other things.

A classic example of such a "5 year works out of the box" example, is a SAP_ALL minus a few things type role (imported manual authorizations into the role from SAP_ALL). That is a snapshot of SAP_ALL and any new objects introduced (with proposals introduced hopefully as well in SU24) will be unknown to it when you apply Support Packs or upgrade or add custom checks. It is bound to fail sooner or later, even although you think it cannot go wrong. A proliferation of SAP_NEW is a nice example of the symptom.

Currently the new object S_RO_OSOA is causing all sorts of havoc in this area (woth keepng an eye out for that one if it has not confronted you yet!) ....

Cheers,

Julius

0 Kudos

Additionally note that when monitoring the gateway before creating the files (which is default installation situation you will find yourself in), the programs registering at the gateway will show up as ID's permitted by the secinfo file and not reginfo. This is because for a while a non-existing reginfo file would redirect the ACL check to the secinfo file as an alternative. When secinfo does not exist either, only then does reginfo have the same unrestricted security settings.

This means, after logging the gatweway for a while and creating the secinfo and reginfo files from the traces, the moment you implement the files and read them into the gateway, the prior recorded secinfo IDs "suddenly" convert themselves to the now existing and actually correct reginfo checks and potentially fail.

As a workaround you can first create secinfo and reginfo files with full access before you start logging. This will then record the correct reginfo entries in the trace file.

I have opened a customer message now with these wishes so will close this thread, but please keep the support going..

Cheers,

Julius

0 Kudos

The parameter is called gw/sim_mode and is available as of Kernel 7.21 only (unfortunately). You also need the corresponding SP of basis component for the application parts to become visible.

See SAP Note https://service.sap.com/sap/support/notes/1689663  for more information.

Very big thank you to SAP!!

Cheers,

Julius

0 Kudos

Julius,

Any idea when this note will be released as it is still in status "not released for customers"?

More 'goodies' being added to it? 😉

Regards,

Joris

0 Kudos

It was released for a while but then withdrawn again. Last I heard SAP wanted to backport it to lower kernel levels as well so I guess that takes a lot of backward compatibility testing.

I recommend that you add a "watch" to this wiki to be kept informed about various updates as SAP maintains it regularly -->  http://wiki.sdn.sap.com/wiki/display/Security/Gateway+security+settings+-+extra+information+regardin... 

Cheers,

Julius