Sarbanes Oxley and SQL 2000

Does anyone have any examples of how you split the SA and DBA functions to be
compliant? I have been looking all over the place and I can't find any
documentation on this. I can't believe I work for the only company facing
this Horrible situation.
TIA,
JoeIf by SA you mean Systems Administrator, what we have done is considered that
to be a special SQL Server account that does not exists at the OS level. And
we disable the builtin\administrator account. The SA account is therefore
the DBA account with no or no special OS privileges.
We have also split the OS responsibilities from the DB responsibilities to
separate groups.
Joseph R.P. Maloney, CSP,CCP,CDP
"jaylou" wrote:
> Does anyone have any examples of how you split the SA and DBA functions to be
> compliant? I have been looking all over the place and I can't find any
> documentation on this. I can't believe I work for the only company facing
> this Horrible situation.
> TIA,
> Joe
>|||Thanks for the reply.
I am guessing I am on the same road you are on. I have created a user with
security admin server role that our network security team will use to create
new logins into the server. I have then removed builtin\admins as you did.
the problem is I as a NON SA I can't manage operators, link servers, create
maint plans etc. We are trying to make i tso there has to be at least 2
people involved to commit fraud. this way there isn't one person that can
create a login, log in as that new user change data, and remove the user. No
real audit trail there. I wish threre was a way to remove the add new logins
from SA, but that isn't possible.
Thanks,
Joe
"jrpm" wrote:
> If by SA you mean Systems Administrator, what we have done is considered that
> to be a special SQL Server account that does not exists at the OS level. And
> we disable the builtin\administrator account. The SA account is therefore
> the DBA account with no or no special OS privileges.
> We have also split the OS responsibilities from the DB responsibilities to
> separate groups.
>
> --
> Joseph R.P. Maloney, CSP,CCP,CDP
>
> "jaylou" wrote:
> > Does anyone have any examples of how you split the SA and DBA functions to be
> > compliant? I have been looking all over the place and I can't find any
> > documentation on this. I can't believe I work for the only company facing
> > this Horrible situation.
> >
> > TIA,
> > Joe
> >|||We are trying to make i tso there has to be at least 2
> people involved to commit fraud. this way there isn't one person that can
> create a login, log in as that new user change data, and remove the user.
> No
> real audit trail there. I wish threre was a way to remove the add new
> logins
> from SA, but that isn't possible.
Not sure if you can stop this, but you may be able to track it.
www.lumigent.com
Also, you can be emailed if a new user is created. Put this in a job that
runs once a minute.
declare @.LastCount int
set @.LastCount = 'Hardcode the number of Logins you have.'
declare @.ServerName varchar(128)
set @.ServerName = @.@.ServerName
if
(select count(*) from SysLogins) > @.LastCount
begin
exec master.dbo.xp_smtp_sendmail
@.FROM = @.ServerName
,@.TO = N'ChrisR@.Bla.com'
,@.Subject = 'Login added!'
,@.server = N'255.255.255.255'
,@.Port = 25
end
"jaylou" <jaylou@.discussions.microsoft.com> wrote in message
news:06A6F891-B8AF-4F1C-881B-775F0180D4DB@.microsoft.com...
> Thanks for the reply.
> I am guessing I am on the same road you are on. I have created a user
> with
> security admin server role that our network security team will use to
> create
> new logins into the server. I have then removed builtin\admins as you
> did.
> the problem is I as a NON SA I can't manage operators, link servers,
> create
> maint plans etc. We are trying to make i tso there has to be at least 2
> people involved to commit fraud. this way there isn't one person that can
> create a login, log in as that new user change data, and remove the user.
> No
> real audit trail there. I wish threre was a way to remove the add new
> logins
> from SA, but that isn't possible.
> Thanks,
> Joe
> "jrpm" wrote:
>> If by SA you mean Systems Administrator, what we have done is considered
>> that
>> to be a special SQL Server account that does not exists at the OS level.
>> And
>> we disable the builtin\administrator account. The SA account is
>> therefore
>> the DBA account with no or no special OS privileges.
>> We have also split the OS responsibilities from the DB responsibilities
>> to
>> separate groups.
>>
>> --
>> Joseph R.P. Maloney, CSP,CCP,CDP
>>
>> "jaylou" wrote:
>> > Does anyone have any examples of how you split the SA and DBA functions
>> > to be
>> > compliant? I have been looking all over the place and I can't find any
>> > documentation on this. I can't believe I work for the only company
>> > facing
>> > this Horrible situation.
>> >
>> > TIA,
>> > Joe
>> >