Alteração de dados e segurança do SQL Server

Question

em nosso ambiente qualquer usuário que fizer login com sa poderá alterar qualquer dado da tabela.

então eu escrevo gatilho para capturar dados alterados como quem mudou, de qual IP etc.

CREATE TRIGGER [TRG_Users]
ON [dbo].[UserRights] AFTER INSERT, UPDATE, DELETE
AS

DECLARE @strIP VARCHAR(MAX)

SET @strIP=(SELECT dbo.GetCurrentIP())

IF EXISTS (SELECT * FROM INSERTED) AND EXISTS (SELECT * FROM DELETED)
    --PRINT 'Update happened';
    INSERT INTO Logger(IPAddress,Status)
    VALUES (@strIP,'UPDATE')
ELSE
IF EXISTS (SELECT * FROM INSERTED)
    --PRINT 'Insert happened';
    INSERT INTO Logger(IPAddress,Status)
    VALUES (@strIP,'INSERT')
ELSE
    --PRINT 'Delete happened';
    INSERT INTO Logger(IPAddress,Status)
    VALUES (@strIP,'DELETE')


CREATE FUNCTION [dbo].[GetCurrentIP] ()  
RETURNS varchar(255)  
AS  
BEGIN  
   DECLARE @IP_Address varchar(255);  

   SELECT @IP_Address = client_net_address  
   FROM sys.dm_exec_connections  
   WHERE Session_id = @@SPID;  

  Return @IP_Address;  
  END  

mas o problema é que o usuário pode alterar os dados após desabilitar o gatilho em uma tabela específica.portanto, o gatilho não será acionado e o usuário poderá alterar os dados sem problemas.

então me oriente qual é a melhor maneira de capturar alterações de dados e registrá-las.então ninguém pode ignorar a segurança.por favor, não me diga para desativar a conta sa porque estou procurando uma abordagem diferente para capturar os dados alterados.existe alguma maneira segura no sql server 2005/2008, se sim, por favor, discuta aqui.obrigado

Answer 1

Problema com SA é que todas as verificações de segurança são ignoradas para este login (ou qualquer outro login na função Sysadmin para esse assunto).Então, você não pode revogar qualquer privilégio da SA e também não há nada que você possa fazer no nível de instância que SA não pode ignorar.

Como os outros já disseram, não deixe ninguém entrar como um sysadmin a menos que haja trabalho real sysadmin a ser feito.A melhor prática é desativar o login do SA completamente.

Em um lado cnstruente, sua melhor aposta de outra forma é criar uma sessão de auditoria do SQL Server e usar o log de segurança do Windows como um alvo.Desta forma, você deve, pelo menos, quem e quando parou a auditoria.