Track/Audi the graphical display of a spool request

[former_member193294]

Hello all,

I have the following question: Is it possible to track/audit which user ID is accessing/opening the "type" of a spool request?

I thought it would be a rspo parameter but I haven't found anything related. If it is not possible then the only thing that can be tracked is who is running tcod SP01?

Thanks in advance.

Loukas

[Former Member]

Hi Loukas

Not sure that it is possible to trace/track "User ID accessing/opening the "type" of a spool request"(If it is possible then it will be interesting to know how). However as already stated by you accessing transaction SP01 can be tracked.

Did you check with your developers whether a custom program can be developed to comply with the requirement?

However from audit perspective access to transaction SP01 should be restricted for production environments as viewing others spool is a audit issue. So in prodcution environments users should be granted access to SP02(Display own Spool Requests) only.

Thanks.

Anjan

[former_member193294]

Thanks Anjan for the reply.

Basically I do not think other people have access to SP01. Only the SAP Admins in our team. That is why I am asking if such an audit mechanism could be implemented, so that Admins can track if by mistake a grant to SP01 has been granted to any of our users.

In any case I will check it with the DEV.

Brgds,

Loukas

[Former Member]

>

> However from audit perspective access to transaction SP01 should be restricted for production environments as viewing others spool is a audit issue. So in prodcution environments users should be granted access to SP02(Display own Spool Requests) only.
> 
> Thanks.
> Anjan

Hi Anjan,

I am curious to know which Auditor says SP01 access to view spool requests is a compliance issue.................

ad further to that, you can restrict the usage of SP01 to individual users. Having SP01 in a users authorization does not necessarily mean he/she can view and change all spools of all users, there is a control mechanis built with S_ADMI_FCD

Give it a try, by giving a user SP01 and S_ADMI_FCD with value SPAR

benefit of SP01: you can see the spool requests over a time frame

[Former Member]

>

> Hi Anjan,
> I am curious to know which Auditor says SP01 access to view spool requests is a compliance issue.................

A couple of auditors I know, do. SP01 does not limit the display of spools to the UserID questing, so even with S_ADMI_FCD properly set, you can have a peek at the balance-sheets printed by the CFO. So, IMHO Anjan is correct - limit users to SP02 and no more.

The time-limit argument is incorrect also - usually SP02 will provide you with all your spools that are still resident in the system. If the older ones are missing, it is no fault of SP02 - more likely your Basis-people have been running RSPO1041 (or it's brethren) with a time-span that deletes spool-requests after a 'defined' time of residency.

[Former Member]

A couple of auditors I know, do. SP01 does not limit the display of spools to the UserID questing, so even with S_ADMI_FCD properly set, you can have a peek at the balance-sheets printed by the CFO. So, IMHO Anjan is correct - limit users to SP02 and no more.

Hi Mylene,

There could be a 1000 who would say so.....but it cannot be a compliance issue in the literal terms of compliance, you call it a operational risk can be a agreed argument (maybe Alex an add value on this)

SP01 combined with S_ADMI_FCD value SPAR, was it wishful thinkig that you could peek the balance sheets printed by the CFO (or) did someone test this

the only editable fields you would get with the combination i mention are the Spool request number, and the date..........try giving a different spool request number than the one you generate........and have a look at the result

I didnt check about the SP02 transaction, but you could be right, i give it to you

[Former Member]

Looks like Loukas has found what he was looking for...

But I am not one to miss an interesting discussion, so would also like to add that operational risks are well within the domain of internal auditors to take under their loop.

If liabilities such as legal risks could arise from unauthorized access to data, external (financial) auditors might even have a leg to stand on as well.

> the only editable fields you would get with the combination i mention are the Spool request number, and the date..........try giving a different spool request number than the one you generate........and have a look at the result

Interesting. It would appear that the behaviour in the end is the same - but I would not place too heavy bets on it yet until you try out all the menu options and function keys.

I will take a closer look. Anyway, the safer bet is to delete the request immediately after it is no longer needed.

Cheers,

Julius

[Former Member]

>

>

> But I am not one to miss an interesting discussion, so would also like to add that operational risks are well within the domain of internal auditors to take under their loop.

>

> If liabilities such as legal risks could arise from unauthorized access to data, external (financial) auditors might even have a leg to stand on as well.

>

This is a topic away from SP01 and SP02......but i would like to keep my learning going...

Internal auditors having a problem with such access has every meaning to it, since they are supposed to be the guys who set th control procedures in place and the operational issues do fall under theri purview.........but i am not too convinced on what kind of data could cause a finanical disaster for the external auditors to object to have access to SP01 (anyway as i mentioned controlling via S_ADMI_FCD does put a lid on it)

cheers and good to know you are live and kickin' and back from your vacation hope you enjoyed

[former_member193294]

I am not sure I have got the right answer but at least I have found some hints to pass the info to the person asked me.

In any case I thank all the people answered so far.

Indeed it is an interesting discussion

Brgds,

Loukas

[Former Member]

You are welcome to keep the thread open and follow-up when you have it wrapped up.

@ Shekar: Have you tried to redirect the spool request to a different output device? Or change the "owner" (field SPOAUTH of S_SPO_ACT)?

If the data is sensitive in any nature, then the less places you leave it parked redundantly, the better.

Cheers,

Julius

Edited by: Julius Bussche on May 19, 2010 9:42 PM

[Former Member]

Hi Julius,

If we construct the authorizations well, SP01 would work the way i suggeste (at least that is the way i see in the system)

If we restrict the user on the printers he can access via objects S_SPO_DEV and S_SPO_PAGE and in the Object S_SPO_ACT you do not maintain the value to change the owner and if S_ADMI_FCD is set to SPAR only, i see no hassles in using it

In generic terms i agree to your point of keeping the data access in limited places and avoid redundancy

[Former Member]

The Auditor job is also make sure that the processes / controls are working properly. Not just SoD conflicts. For example, if you say user has to send in a template while requesting access they do check some random tickets to see whether the process has followed.

To narrow down the subject, if the pay roll administrators / HR / Some finance users usually print the confidential documents. It is not mandatory for every print they give has "Authorization" name associated. So the end users can see the documents which are confidential.

The auditor job is to ensure that this process is working fine and data has not compromised. Determining the scope of auditor completely lies with the engagement.

Hope it clarifies.

Regards,

Gowrinadh

[Former Member]

Hi Gowrinadh,

Your reply does not clarify what i am asking. I understand about what an auditor should/shouldnt do and the role of internal compliance and audit teams - but the point in debate was, why is that we cannot give SP01 to an end user with the authorization values as mentioned in my earlier post..........

[Former Member]

I have to give it to you that a user with the correct authorizations and no additional access (highly unlikely) will experience almost identical system behaviour in the transactions SP01 and SP02.

- 3 differences are that the screens and PAI (Process After Input) modules are different, so there are more menu options in SP01 even although the program is the exact same one.

- You can display an overview of spool locks, so if you could provoke an entry in the overview to appear then other S_SPO_ACT actions could be used on them (e.g. redirect to a local printer).

- The SU24 proposals will tempt many folks into granting much more than just SPAR admi action. This also plays a role in the choice of transaction, and I often create "dummy" transactions for the identical programs or ones which do nothing to achieve the same.

We can write a PhD about this.... but perhaps if you explain why you want SP01 with enhanced options in the stead of SP02 then it will be clearer, despite all urban legends being in your disfavour..

Cheers,

Julius

ps: Yes, thank you. I had a very adventurous vacation

[Former Member]

> We can write a PhD about this.... but perhaps if you explain why you want SP01 with enhanced options in the stead of SP02 then it will be clearer, despite all urban legends being in your disfavour..

> Cheers,

> Julius

Julius,

the discussion was never meant to be on what "I" want or dont want - it was about what can / cannot be done

by the way, did you know that - one of the synonym for a LEGEND is a "MYTH", i suppose it is better to be _Immortal_ than be a Myth,

I suppose you / and the mythical ones would agree atleast to this (C'mon It is about english synonyms and not about security, so you can be in my favour - for once)

Cheers,

Edited by: Shekar.J on May 21, 2010 1:20 PM

[Former Member]

Hi Loukas,

I am not sure if you can track the user opening particular spool request type (SAP Script, ABAP lists.....)

I know i am treading on thin-ice when i am trying on this but neverthless let me give it a try

If you look at the spool request attributes we would see that there is a authorization value to be checked, i suppose we could make use of this field, I would think that the print program that generates the spool request should fill this field value (different for different spool types...) and then you can restrict a user from printing specific types with the object S_SPO_ACT

[Former Member]

Hi,

You can check this by enforcing restriction on accessing different types of spool requests by different users( a lengthy way)

You can go through the below link for more details :

If not, then you can easily track who all have SP01 assigned to them.

Hope this helps.

Regards,

Manisha

[Former Member]

There's no tracking this with SAP standard methods. Follow Anjan and limit your users to SP02 (which you can track in ST03N ...).

May I ask, what your requirement for this question is (just curious)?

[former_member193294]

I was asked by a friend who is working as SAP freelancer in the HR area (functional). He would like to implement such a solution for his customer. He asked me for info, I checked between my colleagues and noone had an idea if is possible with SAP standard functions.

Apparently DEV could try and implement a solution.

Thanks anyway.

[Former Member]

If this is for ESS, then a solution which works is to only use the spool to "bounce" the file back to the user. After generation, immediately delete the spool request.

You can still control via authorizations (see the FAQ thread at the top of the forum) which can be checked via SUIM, and for the admins the risk is just a micro-second long and random user behaviour wide...

Another option is to immediately archive them and control the access there.

Cheers,

Julius