Re: [sap-security] S_DEVELOP in production system roles
Posted by
Admin at
|
Share this post:
|
|
0 Comments
 | Posted by anjan.pandey on May 9 at 11:29 PM |  Mark as helpful |
Agreed with Henrik.. If the access needs to be restricted on program name
then we need to have a custom object created. S_Program checks for program
group..
Thanks
Anjan Pandey
On Sun, May 9, 2010 at 1:22 PM, henrikmadsen2 via sap-security <
sap-security@groups.ittoolbox.com> wrote:
>
> Posted by henrikmadsen2 (GRC
> Consultant )
> on May 9 at 9:03 AM
> No, actually it can't. It can be secured by program group - and the problem
> with that is that if you have access to one group, you have access to all
> programs that are not in any group... That's just the way authoristion
> groups work in SAP...
>
> The only safe method is to ensure custom transactions for all custom
> programs!
>
> /henrik
> On 09/05/2010, at 8:59 , wilderlatino via sap-security wrote:
>
> >
> > Posted by wilderlatino (Technical Consultant)
> > on May 8 at 7:26 PM Mark as helpful
> > Why did you do this? SA38 already can
> > be secure by program.
> >
> > Wilder Latino
> > wilderlatino@yahoo.com
> >
> > On May 8, 2010, at 5:29 PM, "dback via sap-security" <
> sap-security@Groups.ITtoolbox.com> wrote:
> >
> >
> > We actually have a custom zx_sa38 and added a z object to secure by
> program name. This was way we can grant access by program name and ranges of
> names. This is mainly for IT support type or superusers.
> > --------------------------
> > Sent from my BlackBerry Wireless Device
> >
> >
> > ________________________________
> >
> > From: Murray_Girl via sap-security <sap-security@groups.ittoolbox.com>
> > To: Back, Deborah
> > Sent: Sat May 08 12:47:13 2010
> > Subject: Re: [sap-security] S_DEVELOP in production system roles
> >
> >
> > Posted by Murray_Girl (SAP Security Administrator)
> > on May 8 at 12:45 PM Mark this reply as helpfulMark as helpful <
> http://it.toolbox.com/api/ContentVote/3490264/1/1/>
> > There is always an alternative but it does not make any sense to create a
>
> > ZSA38.
> > Create a custom transaction code for the program and then give
> > authorization for the new transaction.
> > No need for SA38.
> >
> > Sonia via
> > sap-security
> > <sap-security@Gro To
> > ups.ITtoolbox.com <http://ups.ittoolbox.com/> Murray_Girl
> > > cc
> >
> > 05/07/2010 11:41 Subject
> > PM Re: [sap-security] S_DEVELOP in
> > production system roles
> >
> > Please respond to
> > sap-security@Grou
> > ps.ITtoolbox.com <http://ps.ittoolbox.com/>
> >
> > (Embedded image moved to file: pic20807.jpg)
> > Posted by Sonia (Sap Basis and Securiy Analyst)
> > on May 8 at 1:33 AM
> > Mark this reply as
> > helpfulMark as helpful
> > Hi,
> >
> > I agree with u.
> > I know both are risky, But when compared with Se38, SA38 is much better.
> go
> > for custome transaction Zsa38.
> > what I mean is if there is no alternative, then go with SA38.
> >
> >
> > Thank you,
> > Sonia
> >
> > On Fri, May 7, 2010 at 5:57 PM, henrikmadsen2 via sap-security <
> > sap-security@groups.ittoolbox.com> wrote:
> >
> > >
> > > Posted by henrikmadsen2 (GRC
> > > Consultant )
> > > on May 7 at 5:54 PM
> > > Sonia,
> > > SA38 gives access to run all programs not assigned to a program group.
> > > Plenty of those around. SA38 is NOT safe to give in PRD
> > > On 08/05/2010, at 5:41 , Sonia via sap-security wrote:
> > >
> > > >
> > > > 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?
__.____._ then we need to have a custom object created. S_Program checks for program
group..
Thanks
Anjan Pandey
On Sun, May 9, 2010 at 1:22 PM, henrikmadsen2 via sap-security <
sap-security@groups.ittoolbox.com> wrote:
>
> Posted by henrikmadsen2 (GRC
> Consultant )
> on May 9 at 9:03 AM
> No, actually it can't. It can be secured by program group - and the problem
> with that is that if you have access to one group, you have access to all
> programs that are not in any group... That's just the way authoristion
> groups work in SAP...
>
> The only safe method is to ensure custom transactions for all custom
> programs!
>
> /henrik
> On 09/05/2010, at 8:59 , wilderlatino via sap-security wrote:
>
> >
> > Posted by wilderlatino (Technical Consultant)
> > on May 8 at 7:26 PM Mark as helpful
> > Why did you do this? SA38 already can
> > be secure by program.
> >
> > Wilder Latino
> > wilderlatino@yahoo.com
> >
> > On May 8, 2010, at 5:29 PM, "dback via sap-security" <
> sap-security@Groups.ITtoolbox.com> wrote:
> >
> >
> > We actually have a custom zx_sa38 and added a z object to secure by
> program name. This was way we can grant access by program name and ranges of
> names. This is mainly for IT support type or superusers.
> > --------------------------
> > Sent from my BlackBerry Wireless Device
> >
> >
> > ________________________________
> >
> > From: Murray_Girl via sap-security <sap-security@groups.ittoolbox.com>
> > To: Back, Deborah
> > Sent: Sat May 08 12:47:13 2010
> > Subject: Re: [sap-security] S_DEVELOP in production system roles
> >
> >
> > Posted by Murray_Girl (SAP Security Administrator)
> > on May 8 at 12:45 PM Mark this reply as helpfulMark as helpful <
> http://it.toolbox.com/api/ContentVote/3490264/1/1/>
> > There is always an alternative but it does not make any sense to create a
>
> > ZSA38.
> > Create a custom transaction code for the program and then give
> > authorization for the new transaction.
> > No need for SA38.
> >
> > Sonia via
> > sap-security
> > <sap-security@Gro To
> > ups.ITtoolbox.com <http://ups.ittoolbox.com/> Murray_Girl
> > > cc
> >
> > 05/07/2010 11:41 Subject
> > PM Re: [sap-security] S_DEVELOP in
> > production system roles
> >
> > Please respond to
> > sap-security@Grou
> > ps.ITtoolbox.com <http://ps.ittoolbox.com/>
> >
> > (Embedded image moved to file: pic20807.jpg)
> > Posted by Sonia (Sap Basis and Securiy Analyst)
> > on May 8 at 1:33 AM
> > Mark this reply as
> > helpfulMark as helpful
> > Hi,
> >
> > I agree with u.
> > I know both are risky, But when compared with Se38, SA38 is much better.
> go
> > for custome transaction Zsa38.
> > what I mean is if there is no alternative, then go with SA38.
> >
> >
> > Thank you,
> > Sonia
> >
> > On Fri, May 7, 2010 at 5:57 PM, henrikmadsen2 via sap-security <
> > sap-security@groups.ittoolbox.com> wrote:
> >
> > >
> > > Posted by henrikmadsen2 (GRC
> > > Consultant )
> > > on May 7 at 5:54 PM
> > > Sonia,
> > > SA38 gives access to run all programs not assigned to a program group.
> > > Plenty of those around. SA38 is NOT safe to give in PRD
> > > On 08/05/2010, at 5:41 , Sonia via sap-security wrote:
> > >
> > > >
> > > > 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?
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
Related Content
In the Spotlight
White Papers
In the Spotlight
Earn Recognition for Your Contributions at Toolbox for IT. Gain Points for Community Achievements
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
