Changement de données SQL Server et sécurité

Question

Dans notre environnement tout utilisateur qui se connecte avec SA, ils peuvent changer les données de la table.

Alors j'écris la gâchette pour capturer des données modifiées comme qui changent, à partir de laquelle IP, etc. Ceci

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  

Mais le problème est que l'utilisateur peut modifier des données après avoir désactivé la gâchette sur une table spécifique.Donc, la gâchette ne sera pas incendie et l'utilisateur peut changer de manière transparente des données.

Alors guide-moi quelle est la meilleure façon de capturer le changement de données et de les enregistrer.Donc, personne ne peut contourner la sécurité.S'il vous plaît ne me disiez pas désactiver le compte SA, car je cherche une approche différente pour capturer les données de changement.Existe-t-il de manière sécurisée dans SQL Server 2005/2008 si oui, veuillez discuter ici.merci

Answer 1

Problème avec SA est que tous les contrôles de sécurité sont ignorés pour ce login (ou tout autre identifiant dans le rôle Sysadmin à cet égard).Donc, vous ne pouvez rien révoquer de privilège de SA et que vous ne puissiez rien que vous puissiez faire le niveau d'instance que SA ne puisse pas contourner.

Comme les autres déjà dit, ne laissez personne se connecter comme une sysadmin à moins qu'il y ait de vrai travail de Sysadmin.La meilleure pratique consiste à désactiver tout le login SA.

sur un côté cnstrant, votre meilleur choix autrement, c'est créer une session d'audit SQL Server et utiliser le journal de sécurité Windows comme cible.De cette façon, vous savez au moins qui et quand vous avez arrêté l'audit.