Access to ABAPER On Production

[former_member182034]

Dear All Experts,

Here, ABAPERs want to access of Debugger, SE16, SE37, SE38, SE80 on Production Server while due to security reasons I have denied number of time but every time when they went in trouble, they demand of debug and show the accuses that some scenarios and batch does not exist on Quality Assurance Server(QAS), that's why we need the access of debug on production server . If you can't give the access of Debug then please provide us Quality Assurance Server on daily basis while I am providing the copy(QAS) of PRD after a month.

Please guide me and explain about the access of these tcodes to ABAPER.

be frankly just tell me that. should the ABAP user exist on PRD or not wrt security purpose?

Thanks and Best Regards,

[Former Member]

HI Jamil,

Due to security reasons access to certains codes must be restricted.Because in production server the client live data is exist .If some one edit the entries of tables then it shows huge impact on client buisness.The Tcodes SE16,SE11,SE16N should be restrict the access.

Regards

Khaleel

[Former Member]

Is Firefighter process implemented in the project if yes then why not create a create a diff role and assign to a FF id and make these ABAPERS to use that ID rather than giving access to their own id,

[Former Member]

Hi Abdul,

Yes you are right in denying to give access to developers in Production system.

They must replicate the same scenario that is available in Production and do the Quality Testing in Quality System which is designed for the Testing Purpose.

Its the 1st step to close the entry to developers in Production.

Workaround:

1. You can give access to them in Display mode for Object type DEBUG but ensure that Access Key was not given to that User ID ever before.
2. For more security, You can give this debugging access to Functional Consultant's ID as they never get Access Key in systems.

Regards,

Ramakrishna

[Former Member]

Hi ,

ABAPers are provided "debug" option in Production , there is no harm in that. As you don't replicate the P to Q on daily basis,so in crictical scenarios they need "Debug" authorizaion.  but double ensure the following:

1) Create & change activity is not assigned in S_DEVELOP object.

2) Also without SSCR key , ABAPer can neither create or change any object , so its always  recomended that user id should be different in Dev and Prod .

3) Production is Close Client and Global namespace settings are Non-Modifiable , so they won't be able to change any object.

Regards,

Deepak

[Former Member]

I encountered the same issue. Our solution was providing the developers access to production in display only mode. If there where really issues in Production we have created a self developed firefighter solution. The developer can use this firefighter with wide access after the approval procedure and everythng is logged and monitored.

No debugging access in given in production except for the special firefighter.

[Former Member]

Abdul,

If you’re asking if it is okay to have access in their everyday support role the answer is NO.
If it is a one-time thing as you say to troubleshoot issues that cannot be
duplicated in production than you should implement a change control process
where this type of request is approved by people at the top of the food chain
for accountability and also make sure to provide documentation on misuse of
access will lead to corrective actions. Usually when ABAPers see this they seem
to find other routes in resolving issues without needing such critical access. 

At the end of the day the goal is protecting the integrity of the data in production and not having ABAPers go in make changes in production purposely or inadvertently which is the
big RISK.

Lastly, SE16 is okay to give in production so as long as you make sure the right table groups
are assigned in S_TABU_DIS with display access and no create/change for S_DEVELOP. 

-Wes

[ganesh_s7]

Abdul,

Agree with Wes.  Seems ABAPer's believe you are the approving authority and hindering access.  Once they know it is out of your hands and they have to follow a formal process of approval, most ad-hoc requests drop. 

A few genuine ones do come up now and then (once in a bluemoon) and that can be given via GRC Firefighter (if you have GRC in landscape) else with proper business approver.  Have a talk with the Data Owner (Client side) and formulate a plan if don't have one already.

BR, Ganesh

[former_member182034]

Dear All,

Here again same issue, scenario is, BAPI/program executed the 24 batches and suddenly does not execute the next batch mean batch number 25, ABAPER is demanding debug access on Production system while we already granted more then 4 time access of debug for same scenario.  when I said to ABAPER that why you people does not rectify the program error then they are saying me that there is no solution of this error. We need debug access to find out the program error for same scenario whenever we face this issue.

what do you say about ABAPER mean why they are demanding the debug access instead rectify the program?

due to some reason, I can't use firefighter.

Regards,

[ganesh_s7]

Hi Jamil,

If you are using ID based FF id access, suggest you create a FF Id for Debug access and give it to the abaper or just maintain debug access to one FF id (time limieted ?), this way he should get Debug access via FF Id.

Do have in Mind FF id with Debug generate a lot of logs.

Rgds

Ganesh.S

[Former Member]

Hi,

Is there a SAP note which recommends that there shouldn't be any developer with a developer key in the production system? Please let me know.

Regards,

[Colleen]

basic security 101 due to risk

[Former Member]

Please do not "necro-post" old threads.

If your authorizations and system / client change settings are correct, then the existence of a developer key will never be asked for.

Developer key does not override developer access authorizations. If anything the developer authorization check is sometimes missing and a developer will not need a key in such cases (debugging with changing variables or maintenance of some sensitive system tables which at runtime become code).

-> If your authorization concept is OK, then you dont need to bother about DEVACCESS too much. There is no maintenance view for it so it is actually a useful record to document emergency changes which can happen from time to time.

Cheers,

Julius