DEVACCESS table maintenance

[Former Member]

Hi everyone,

Is there a way to maintain the DEVACCESS table? We need to maintain this table for added security, since there are userid's (developers) in our system who are no longer connected with the company and we want to delete the active developer access keys of these users from the said table.

Is there a security risk at all if these access keys were just left active in the table? Would SAP recommend these keys to be deleted from the DEVACCESS table?

Thanks,

Kris Caldoza

[former_member81915]

Found this in one of the forums...

DEVACCESS table entries are automatically maintained by SAP as and when an ABAP'ER is registered in the Development system. Any Developer who leaves the Organization has to be expired in his User Master Record. This will also ensure that his User Master Record is not chargeable for License as the User is expired.

Also...

ABAP program to delete records from this table:

REPORT Z17DEVACCESS.

tables: devaccess.

parameters: p_user like devaccess-uname.

delete from devaccess where uname eq p_user.

if sy-subrc eq 0.

write: / 'User ', p_user, ' deleted.'.

else.

write: / 'Error deleting user ', p_user, ' return code ', sy-subrc.

endif.

....a few of them also used SM31 to delete the entires.. i tired but cud not do it...

Regards

Sachin

[Former Member]

Thanks Sachin for all the information. They were very helpful.

About the ABAP program, does it delete the entry one-by-one?

Thanks again.

[Former Member]

One security risk I've pointed out to clients is that if you leave the entry in DEVACCESS and your termination policy is to delete users, then if you ever create a new user with the exact same userid, that userid will have a dev key entered for them. Simply disabling them in the Marketplace doesn't remove it from the table, and I've deleted entries from DEVACCESS with no problems.

[Former Member]

What about the case where there are multiple users assigned to the DEVACCESS table, however, the users have been removed from the system. What is the risk of this if the same exact user IDs aren't used when creating other users? Is there any possible way for the user IDs with the DEVACCESS keys to be accessed by other users?

It sounds like this may just be an item that needs to be cleaned-up by removing the users with DEVACCESS in SAP Marketplace if the users are no longer active. Is that correct?

[Former Member]

A few things to bare in mind:

1 Never use the same uid again (for an other person) on a SAP system, as there are many things

linked to the uid. (audit trails, dev key etc)

2 deleting a dev key is a good step in the whole process but does not help as long as the same person is still on the system with teh same uid, he/she can just reenter the key and has dev access again. The key is nothing else than an algorithem based on system number and UID and some other system values.

3 as some companies build prd systems as a database copy of the dev system and do not change the system number afterwards, the same key THEN is valid for the PRD system also. SO no developer should be allowed access to the PRD system with the same UID as in DEV!

Make use of the above info for setting up a secure landscape

[Former Member]

I agree with Auke.

As has been pointed out in this thread and a few others on the topic in the past, developer keys are more an organization control and licensing mechanism.

However there is a good security reason to delete the keys and ensure access to them is restricted for systems with the same installation number: It raises the security wall against someone wanting to create / change programs in the system such that they would need to jump the wall and make more noise when doing so.... so you have a better chance of detecting it.

I am not aware of any SAP standard tool to clean DEVACCESS (last I heard there is none), however SAP told us it is okay to do it ourselves, so we created a tool for it.

Cheers,

Julius

[Former Member]

Hello everybody ...

may I make a little remark ?

I would suggest to switch on table-logging (SE13) on DEVACCESS.

By doing that and by regularily deleting items in DEVACESS as described already you create a much better trail of DEVACCESS entries over time.

That should make the real usage of developer keys much more visible.

Best regards,

Ralf

[Former Member]

Hello Ralf,

Yes, recording the key fields via table logging (read by SCU3)can help for auditing purposes, but recording the keys themselves would not make sense...

... at least not more than any other source for the same valid key to "create less noise"...

Perhaps things have changed in higher releases, but I doubt it.

Cheers,

Julius