Discussion :

[Ptit_Dje]

Bonjour bonjour,

Lors de la creation d'une specification d'audit au niveau d'une base de donnees, le nom d'un principal est requis.
Utilisant un modele de securite base sur de groupes AD, je souhaiterai mettre en place un audit sur les actions select/insert/update/delete executees par les membres d'un groupe AD appele ADSysadminGroup.

Soit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
USE Test_audit
GO
 
CREATE DATABASE AUDIT SPECIFICATION [ADGroupAudit_Specification]
FOR SERVER AUDIT [ADGoupAudit]
ADD (DELETE ON DATABASE::[test_audit] BY [Domaine\ADSysadminGroup]),
ADD (INSERT ON DATABASE::[test_audit] BY [Domaine\ADSysadminGroup]),
ADD (UPDATE ON DATABASE::[test_audit] BY [Domaine\ADSysadminGroup]),
ADD (DELETE ON DATABASE::[test_audit] BY [Domaine\ADSysadminGroup]),
WITH (STATE = ON)
GO

Le fait est que, en tant que membre de ce groupe AD, lorsque j'effectue une action au niveau de la DB, mes actions ne sont pas auditees.

Est ce que quelqu'un aurait une solution pour resoudre cela ?
Genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
BY [Domaine\ADSysadminGroup].MEMBERS()
BY MEMBERS::[Domaine\ADSysadminGroup]

Le but etant de filtrer les actions effectuees par les sysadmins au niveau des donnees sans pour autant devoir auditer toute l'activite se passant sur la DB par soucis d'economie de place.

Merci d'avance pour vos idees

[mikedavem]

Lut

Tu ne pourras pas faire cela car les objets de spécification d'audit au niveau base de données et pour l'action auditée n'acceptent comme les principals de ce niveau (users, roles).

Même en définissant un user et en le mappant à ton compte de connexion correspondant au groupe Windows cela ne fonctionne pas ...

Le seul moyen (que j'ai trouvé avec les audits) est d'auditer les événements DML sur le schéma .. mais cela peut faire grossir ton journal d'audit rapidement ... bref pas de moyen simple dans ce cas ..

Si tu trouves une parade je suis preneur ..

++

[Ptit_Dje]

Tcho Mike,

Je lisais hier sur connect qu'il parlait d'implementer une fonctionnalite AUDIT ALL EXCEPT...
Avec cette fonctionnalite, ca permettrait en effet d'arriver plus facilement a mettre en place la solution souhaitee, en auditant tout sauf les actions du service account utiliser par l'application.
De ce fait on pourrait avoir une vue sur toutes les activites transactionnelles non-liees au fonctionnement normal de l'application.

Il semblerait par contre qu'on doive attendre encore un peu pour cela...

Au passage, sur la page http://www.microsoft.com/sqlserver/2...ompliance.aspx, il y a tout en dessous un pack d'exemples tres interessants.
En effet il y a la dedans : le script de creation d'une base de donnees format DWH pour stocker les resultats des fichiers d'audit, un package SSIS pour charger les fichiers d'audit (ne pas utiliser de "_" (underscore) dans le nom de l'audit, le fichier SSIS se sert de se caractere comme point de depart pour l'extraction du GUID genere dans le nom du fichier), ainsi que des rapports SSRS predefinis pour rapporter sur la base de donnees.

Bref, un bon starting point pour mettre en place une solution globale d'auditing

Il y a le meme genre de scripts pour le management des policies... Et comment deployer en utilisant du powershell, j'ai pas encore vraiment regarder par contre ca semble etre du meme accabis.


Bonne journee,
Dje

[mikedavem]

En effet il y a la dedans : le script de creation d'une base de donnees format DWH pour stocker les resultats des fichiers d'audit, un package SSIS pour charger les fichiers d'audit (ne pas utiliser de "_" (underscore) dans le nom de l'audit, le fichier SSIS se sert de se caractere comme point de depart pour l'extraction du GUID genere dans le nom du fichier), ainsi que des rapports SSRS predefinis pour rapporter sur la base de donnees.

Oui c'était bien la suite logique pour ce genre de fonctionnalités ... surtout pour les clients qui possèdent une multitude de bases etc .... :-)

Il y a le meme genre de scripts pour le management des policies... Et comment deployer en utilisant du powershell, j'ai pas encore vraiment regarder par contre ca semble etre du meme accabis.

Oui pour le management policy tu peux tout faire par powershell en effet.

Sur mon article j'avais testé pour un ancien client un framework pour faire du reporting derrière tout ça. Très intéressant.

A+ ;-)