Cambio e sicurezza dei dati del server SQL

Question

Nel nostro ambiente qualsiasi utente che accede con SA possono modificare i dati della tabella.

Quindi scrivo il trigger per catturare i dati modificati come Change What, da quale IP ecc. Questo

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  

.

Ma il problema è che l'utente può modificare i dati dopo aver disabilitato il trigger sulla tabella specifica.Quindi il grilletto non spazzerà e l'utente può cambiare perfettamente i dati.

Quindi guidami qual è il modo migliore per catturare la modifica dei dati e registrarli.Quindi nessuno può bypassare la sicurezza.Per favore non dirmi disabilitare un account SA perché sto cercando un approccio diverso per acquisire i dati di modifica.Esiste un modo sicuro in SQL Server 2005/2008 se sì, si prega di discutere qui.Grazie

Answer 1

Problema con SA è che tutti i controlli di sicurezza vengono saltati per questo login (o qualsiasi altro login nel ruolo sysadmin per tale questione).Quindi, non puoi revocare alcun privilegio da SA e anche non c'è nulla che tu possa fare a livello di istanza che SA non può bypassare.

Come gli altri hanno già detto, non permettere a nessuno di accedere come sysadmin a meno che non ci sia il vero lavoro sysadmin da fare.La migliore pratica è di disabilitare il login SA del tutto.

Su un lato cnstructive, la migliore scommessa altrimenti è quella di creare una sessione di audit di SQL Server e utilizzare il registro di sicurezza di Windows come obiettivo.In questo modo sarai almeno chi e quando si fermò l'audit.