Déterminer si la procédure stockée peut s'exécuter en fonction de la connexion AD

Question

J'ai une procédure stockée qui met à jour les données d'une table pour un enregistrement spécifique. J'ai plusieurs utilisateurs qui utiliseront cette procédure stockée mais je veux seulement qu'ils puissent mettre à jour les enregistrements qui leur sont assignés.

Chaque enregistrement qui doit être mis à jour par la procédure stockée a un champ nommé "UserID" qui définit qui a le contrôle sur l'enregistrement. J'ai également une table de mappage qui mappe les connexions actives d'annuaire aux ID d'utilisateur. J'utilise Active Directory pour que SQL Server sache qui tente d'exécuter la procédure stockée. Existe-t-il un moyen, dans la procédure stockée, de rechercher les informations de connexion du répertoire actif des utilisateurs dans une autre table, puis de déterminer si elles ont accès aux enregistrements qui tentent d'être mis à jour?

Answer 1

Vous pouvez savoir qui est l'utilisateur actuel dans le processus en appelant SYSTEM_USER et en l'intégrant dans la requête qui met à jour les lignes.

Answer 2

Je ne suis pas un concepteur d'applications mais en surface, votre solution me semble inutilement compliquée. Cela dit, vous pouvez lancer la requête suivante pour obtenir le nom de connexion AD Windows de l'utilisateur qui exécute actuellement la procédure stockée. Vous pouvez utiliser cette information pour faire des références croisées avec votre table de mappage afin de déterminer si le compte AD dispose des privilèges requis pour effectuer l'opération.

SELECT SYSTEM_USER 

Gardez à l'esprit que ce retourne le nom du contexte en cours d'exécution, alors gardez à l'esprit que cela peut être explicitement modifiée à l'aide du paramètre « Exécuter en tant que » déclaration.

EDIT:

Je me demande si une vue pourrait être utilisé pour limiter les données visibles à un compte AD donné. La logique de la procédure stockée peut alors se concentrer sur l'aspect de la modification des données plutôt que sur l'implémentation de la sécurité. Le contrôle de l'accès aux données à l'aide de vues garantit également qu'une méthode d'accès de sécurité cohérente est utilisée pour plusieurs procédures stockées si nécessaire, par opposition à la mise en œuvre d'une vérification de sécurité dans chaque procédure.

Depuis la rédaction de ce, le lien fourni par Martin Smith, détails comment cette solution peut être mise en œuvre:

Granting Row-Level Permissions in SQL Server

En conclusion, une combinaison des deux est de savoir comment Microsoft vous suggère de mettre en œuvre la solution à votre problème .

Answer 3

Cet article vous aide-t-il? Granting Row-Level Permissions in SQL Server

Il recommande les étapes suivantes

• Créez la table, en ajoutant une colonne supplémentaire pour enregistrer le nom.
• Créez une vue qui a une clause WHERE basée sur la colonne du nom d'utilisateur. Cela limitera les lignes renvoyées à celles ayant la valeur spécifiée. Utilisez l'une des fonctions intégrées pour spécifier un utilisateur de base de données ou un nom de connexion. Cela élimine le besoin de créer des vues différentes pour différents utilisateurs.
• Créez des procédures stockées pour sélectionner, insérer, mettre à jour et supprimer des données en fonction de la vue, et non des tables de base. La vue fournit un filtre qui limite les lignes renvoyées ou modifiées.
• Pour les procédures stockées qui insèrent des données, capturez le nom d'utilisateur en utilisant la même fonction spécifiée dans la clause WHERE de la vue et insérez cette valeur dans la colonne UserName.
• Refuser toutes les autorisations sur les tables et les vues au rôle public. Les utilisateurs ne pourront pas hériter des autorisations d'autres rôles de base de données, car la clause WHERE est basée sur les noms d'utilisateur ou de connexion, et non sur les rôles.
• Accordez EXECUTE sur les procédures stockées aux rôles de base de données. Les utilisateurs peuvent uniquement accéder aux données via les procédures stockées fournies.