Discussion :

[Donpi]

Bonjour,

Quelqu'un connait-il un moyen de mettre un trigger sur la modification de cette table system ?

Jusqu'à 2016 ( 2017 aussi je crois mais pas sûr ) le contenu de cette table était stocké dans les extended properties.
Du coup un simple trigger DB faisait l'affaire.

Mais depuis 2019 les classification sont dans une table particulière et plus dans les EP.
Et comme on doit pas créer de trigger sur les tables systèmes, je ne sais pas trop comment faire.

Des idées ?

Cordialement,

[mikedavem]

Hello,

Tu cherches à faire quoi exactement avec ce trigger?

++

[Donpi]

Pour le moment tout est hypothétique.
Mais en gros la suisse va appliquer en grande partie la loi européenne sur la protection des données.
Et comme je suis en train de revoir notre architecture, je me dis que c'est l'occasion d'implémenter certains concepts un peu laissé pour comptes jusqu’à présent.

La loi va nous obliger à classifié tous nos attributs, c'est là qu'entre en jeux cette fameuse table sys.sensitivity_classifications.

Une fois que nos données sont classifiées, il est évident que le besoin de droit d'accès par degrés de sensibilité va arriver.

Donc je fais un peu de travail proactif et je regarde les options qui s'offrent à moi.

Celle que j'étudie en ce moment consiste maintenir de façon automatique un rôle dB pour chaque degré de sensibilité.
Ce rôle fait bêtement un DENY sur toutes les colonnes qui sont de ce même niveau.
Et par défaut tous mes utilisateurs sont dans ces rôles.

Avec Sql Serveur 2016 j'ai fait un trigger db sur l'ajout d'une extended property et ça fonctionne plutot bien.
Mais depuis 2019 la sensibilité n'est plus dans les extended properties mais dans sys.sensitivity_classifications..
Donc bla bla bla faut que je trouve une autre approche pour maintenir à jour ces rôles.
Une des possibilités peut être de mettre la mise à jour dans un job de l'agent, mais idéalement j'aimerais un truc un peux plus élégant.

Globalement j'aimerais utiliser au maximum ce qu'il y a en standard dans SQL Server.

J'ai aussi regardé le masquage dynamique, mais le droit UNMASk est scopé au niveau de toute la DB ce qui ne me convient pas.
Par exemple j'aimerais que Finance ait accès en claire aux données de finance mais en masqué aux données de RH et vice et versa ce qui n'est pas possible.
Si tu as accès à l'objet et que tu as UNMASK tu peux tout voir.



PS :
Une partie de moi était tenté de répondre "en quoi c'est important".
Bien souvent sur les forum (ici aussi hein) les gens qui ne connaissent pas là réponse s'obstinent à détourner le sujet de la question initiale pour trouver un moyen de ne pas faire le job.
Et presque à chaque fois on se retrouve à devoir se justifier sans pour autant avoir de réponse.

[SQLpro]

a la place du masquage utilise la sécurité de niveau ligne (row level securirty)

Pour la table système, le mieux est un travail de l'Agent qui peut se déclencher toutes les 10 minutes.

A +