Cambio e sicurezza dei dati del server SQL
-
21-12-2019 - |
Domanda
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
Soluzione
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.