Re: [sap-security] S_DEVELOP in production system roles
Posted by
Admin at
|
Share this post:
|
|
0 Comments
 | 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 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
(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?
__.____._ 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 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
(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
wilderlatinoSAP Security Enthusiast
Contributed 100 posts in a group to earn a Bronze Achievement
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
_.____.__ 
