Re: [sap-security] S_DEVELOP in production system roles
Posted by
Admin at
|
Share this post:
|
|
0 Comments
 | Posted by Sonia (Sap Basis and Securiy Analyst) on May 7 at 3:38 PM |  Mark as helpful |
Hi All,
SA38 doesn't 't have S_develop object when compare with Se38. So in
production we can assign SA38. Instead of disabling the
object S_develop.
Make sure in S_Program : Authgroup : Never give &NC&..
Majority people get confused with SA38 and Se38
Thank you,
Sonia
On Fri, May 7, 2010 at 2:22 AM, anjan.pandey via sap-security <
sap-security@groups.ittoolbox.com> wrote:
> Posted by anjan.pandey
> on May 7 at 2:22 AM
> Hi
>
> Per audit compliance both trxn SA38 and SE38 should not be assigned to
> users
> in production system. Also Query creation(through transaction SQVI) should
> be worked out in development and transported across to production system.
>
> *Note*: Granting access for object S_DEVELOP with ACTVT "03" and object
> Type
> "DEBUG" provides debug access to users. This should not be assigned to
> users
> in production system.
>
> Thanks.
> Anjan Pandey
>
> On Fri, May 7, 2010 at 2:25 AM, henrikmadsen2 via sap-security <
> sap-security@groups.ittoolbox.com> wrote:
>
> >
> > Posted by henrikmadsen2 (GRC
> > Consultant )
> > on May 6 at 4:55 PM
> > But even SA38 should never be granted! Far too many programs are
> entirely
> > unprotected for execution through SA38
> > On 06/05/2010, at 22:00 , Sonia via sap-security wrote:
> >
> > >
> > > Posted by Sonia (Sap Basis and Securiy Analyst)
> > > on May 6 at 8:07 AM Mark as helpful
> > > Hi,
> > >
> > > Its better to understand the difference between SE38 and SA38.
> > > Auditor will always recommend SA38 in production when compare with
> SE38.
> > >
> > > Thank you,
> > > Sonia
> > > On Fri, Apr 30, 2010 at 10:23 AM, benefieldgm via sap-security <
> > > sap-security@groups.ittoolbox.com> wrote:
> > >
> > > > Posted by benefieldgm(SAP Security Specialist)
> > > > on Apr 30 at 10:22 AM
> > > > I've also heard the argument from developers regarding the need for
> > SE38 to
> > > > review code in production. I advised our developers that this can be
> > quite
> > > > easily accomplished by using SE38 in development as follows:
> > > >
> > > > 1. Logon to development system
> > > > 2. SE38; enter name of program to review
> > > > 3. Go to Utilities ? Splitscreen editor
> > > > 4. Enter name of program under 'Right' box
> > > > 5. Click 'Compare Different Systems'
> > > > 6. Enter RFC destination for production environment (ours requires
> that
> > the
> > > > user logon with his own credentials such that the user is constrained
>
> > by his
> > > > own authorizations in production)
> > > > 7. Click 'Display' (user prompted to logon to production)
> > > > 8. Production source code is displayed on right
> > > >
> > > > This allows developers to view source code in production without
> having
> > to
> > > > directly have access to SE38 in production (although it does require
> > that
> > > > the user have an S_DEVELOP Display authorization for the program).
> > Perhaps
> > > > something to consider as an alternative?
> > > >
> > > > Gail
> > > >
> > > > From: henrikmadsen2 via sap-security [mailto:
> > > > sap-security@Groups.ITtoolbox.com]
> > > > Sent: Thursday, April 22, 2010 10:49 PM
> > > > To: Benefield, Gail M.
> > > > Subject: Re: [sap-security] S_DEVELOP in production system roles
> > > >
> > > > Posted by henrikmadsen2 (GRC Consultant )
> > > > on Apr 22 at 10:47 PM Mark as helpful
> > > >
> > > > So they make so many mistakes that they require SE38 full time?
> That's
> > not
> > > > a
> > > > good sign ;-)
> > > > Temporary access as and when needed should be the way to go.
> > > > If you have different versions of your programs in different
> > environments,
> > > > you may want to revisit your change management process.
> > > >
> > > > No one has SE38 in production here - not even in UAT. There is
> > firefighter
> > > > access as and when required, but only on the back of a support
> ticket.
> > > >
> > > > So, it's a matter of how strict you want to be.
> > > >
> > > > On 23 April 2010 06:25, JimmyJ2 via sap-security <
> > > > sap-security@groups.ittoolbox.com> wrote:
> > > >
> > > > > Posted by JimmyJ2(Mr)
> > > > > on Apr 22 at 4:26 PM
> > > > > All,
> > > > > Of course it goes without saying if you have several development
> > teams on
> > > >
> > > > > the go then the version in Dev / Test may be modified but not yet
> > > > > transported to Production. Trying to debug a different modified
> > version
> > > > in
> > > > > Test for a Production issue is the perfect excuse for failing to
> fix
> > a
> > > > > problem quickly and the impact to the business that causes.
> > > > > Cheers, James.
> > > > >
> > > > > ---------------Original Message---------------
> > > > > From: mjc
> > > > > Sent: Friday, April 16, 2010 10:33 AM
> > > > > Subject: S_DEVELOP in production system roles
> > > > >
> > > > > > I removed S_DEVELOP from production system end user roles per the
>
> > > > > S_DEVELOP documentation. However, now users cannot run tcode SE38
> > without
> > > >
> > > > > getting an authorization error pointing to S_DEVELOP. Can someone
> > explain
> > > > to
> > > > > me why this is happening?
__.____._ SA38 doesn't 't have S_develop object when compare with Se38. So in
production we can assign SA38. Instead of disabling the
object S_develop.
Make sure in S_Program : Authgroup : Never give &NC&..
Majority people get confused with SA38 and Se38
Thank you,
Sonia
On Fri, May 7, 2010 at 2:22 AM, anjan.pandey via sap-security <
sap-security@groups.ittoolbox.com> wrote:
> Posted by anjan.pandey
> on May 7 at 2:22 AM
> Hi
>
> Per audit compliance both trxn SA38 and SE38 should not be assigned to
> users
> in production system. Also Query creation(through transaction SQVI) should
> be worked out in development and transported across to production system.
>
> *Note*: Granting access for object S_DEVELOP with ACTVT "03" and object
> Type
> "DEBUG" provides debug access to users. This should not be assigned to
> users
> in production system.
>
> Thanks.
> Anjan Pandey
>
> On Fri, May 7, 2010 at 2:25 AM, henrikmadsen2 via sap-security <
> sap-security@groups.ittoolbox.com> wrote:
>
> >
> > Posted by henrikmadsen2 (GRC
> > Consultant )
> > on May 6 at 4:55 PM
> > But even SA38 should never be granted! Far too many programs are
> entirely
> > unprotected for execution through SA38
> > On 06/05/2010, at 22:00 , Sonia via sap-security wrote:
> >
> > >
> > > Posted by Sonia (Sap Basis and Securiy Analyst)
> > > on May 6 at 8:07 AM Mark as helpful
> > > Hi,
> > >
> > > Its better to understand the difference between SE38 and SA38.
> > > Auditor will always recommend SA38 in production when compare with
> SE38.
> > >
> > > Thank you,
> > > Sonia
> > > On Fri, Apr 30, 2010 at 10:23 AM, benefieldgm via sap-security <
> > > sap-security@groups.ittoolbox.com> wrote:
> > >
> > > > Posted by benefieldgm(SAP Security Specialist)
> > > > on Apr 30 at 10:22 AM
> > > > I've also heard the argument from developers regarding the need for
> > SE38 to
> > > > review code in production. I advised our developers that this can be
> > quite
> > > > easily accomplished by using SE38 in development as follows:
> > > >
> > > > 1. Logon to development system
> > > > 2. SE38; enter name of program to review
> > > > 3. Go to Utilities ? Splitscreen editor
> > > > 4. Enter name of program under 'Right' box
> > > > 5. Click 'Compare Different Systems'
> > > > 6. Enter RFC destination for production environment (ours requires
> that
> > the
> > > > user logon with his own credentials such that the user is constrained
>
> > by his
> > > > own authorizations in production)
> > > > 7. Click 'Display' (user prompted to logon to production)
> > > > 8. Production source code is displayed on right
> > > >
> > > > This allows developers to view source code in production without
> having
> > to
> > > > directly have access to SE38 in production (although it does require
> > that
> > > > the user have an S_DEVELOP Display authorization for the program).
> > Perhaps
> > > > something to consider as an alternative?
> > > >
> > > > Gail
> > > >
> > > > From: henrikmadsen2 via sap-security [mailto:
> > > > sap-security@Groups.ITtoolbox.com]
> > > > Sent: Thursday, April 22, 2010 10:49 PM
> > > > To: Benefield, Gail M.
> > > > Subject: Re: [sap-security] S_DEVELOP in production system roles
> > > >
> > > > Posted by henrikmadsen2 (GRC Consultant )
> > > > on Apr 22 at 10:47 PM Mark as helpful
> > > >
> > > > So they make so many mistakes that they require SE38 full time?
> That's
> > not
> > > > a
> > > > good sign ;-)
> > > > Temporary access as and when needed should be the way to go.
> > > > If you have different versions of your programs in different
> > environments,
> > > > you may want to revisit your change management process.
> > > >
> > > > No one has SE38 in production here - not even in UAT. There is
> > firefighter
> > > > access as and when required, but only on the back of a support
> ticket.
> > > >
> > > > So, it's a matter of how strict you want to be.
> > > >
> > > > On 23 April 2010 06:25, JimmyJ2 via sap-security <
> > > > sap-security@groups.ittoolbox.com> wrote:
> > > >
> > > > > Posted by JimmyJ2(Mr)
> > > > > on Apr 22 at 4:26 PM
> > > > > All,
> > > > > Of course it goes without saying if you have several development
> > teams on
> > > >
> > > > > the go then the version in Dev / Test may be modified but not yet
> > > > > transported to Production. Trying to debug a different modified
> > version
> > > > in
> > > > > Test for a Production issue is the perfect excuse for failing to
> fix
> > a
> > > > > problem quickly and the impact to the business that causes.
> > > > > Cheers, James.
> > > > >
> > > > > ---------------Original Message---------------
> > > > > From: mjc
> > > > > Sent: Friday, April 16, 2010 10:33 AM
> > > > > Subject: S_DEVELOP in production system roles
> > > > >
> > > > > > I removed S_DEVELOP from production system end user roles per the
>
> > > > > S_DEVELOP documentation. However, now users cannot run tcode SE38
> > without
> > > >
> > > > > getting an authorization error pointing to S_DEVELOP. Can someone
> > explain
> > > > to
> > > > > me why this is happening?
Copyright © 2010 Toolbox.com and message author.
Toolbox.com 4343 N. Scottsdale Road Suite 280, Scottsdale, AZ 85251
Toolbox.com 4343 N. Scottsdale Road Suite 280, Scottsdale, AZ 85251
SoniaSAP Security Enthusiast
Contributed 100 posts in a group to earn a Bronze Achievement
Related Content
In the Spotlight
White Papers
In the Spotlight
Your SAP Security is at Risk...Learn How to Stay Protected. Read the free white paper from SenSage
View this thread online
Manage group e-mails
Create an FAQ on this topic
Tell us what you think
Unsubscribe from discussion
Manage group e-mails
Create an FAQ on this topic
Tell us what you think
Unsubscribe from discussion
_.____.__ 
