Autorisations lors de l'utilisation de "Execute sp_Executesql"

J'ai une base de données dans laquelle tous les accès sont contrôlés par des procédures stockées. L'administrateur de base de données aimerait éviter de donner aux utilisateurs un accès direct en lecture/écriture aux tables sous-jacentes, ce que je peux comprendre. Par conséquent, toute mise à jour et sélection de données se fait via des procédures stockées. Fondamentalement, il a créé un rôle qui a des autorisations EXECUTE à toutes les procédures stockées dans la base de données et donné aux utilisateurs ce rôle.Autorisations lors de l'utilisation de "Execute sp_Executesql"

Le problème est que l'une des procédures stockées génère dynamiquement une requête SQl et l'exécute via "Execute sp_Executesql". Sans entrer dans les détails, la requête est construite dynamiquement car elle change de manière significative en fonction de nombreux paramètres d'entrée utilisateur. La procédure stockée en question est seulement une instruction SELECT sql mais je trouve qu'il suffit de donner la permission EXECUTE à la procédure stockée. Les tables sous-jacentes référencées dans la procédure stockée qui utilisent "Execute sp_Executesql" doivent avoir reçu un accès "datareader" sinon la procédure stockée échoue.

Des idées pour corriger la situation? Je voulais vraiment limiter l'accès aux tables aux seules procédures stockées, mais je dois trouver un moyen de contourner les procédures stockées qui utilisent "Execute sp_Executesq" l. Je vous remercie.

Source

2010-09-28 webworm

Vous pouvez obtenir un meilleur serverfault de avdice. Mon conseil - Parlez à la dba et expliquez la situation. Travaillez avec eux pour obtenir les autorisations appropriées. –

-3

Le vrai problème est que sp_Executesql se trouve dans la base de données master, pas nécessairement la base de données dans laquelle vous travaillez. Votre DBA doit donner l'autorisation d'exécuter sp_Executesql à la procédure d'appel. Que quiconque ayant l'autorisation d'appeler cette procédure pourra exécuter sp_Executesql.

Source

2010-09-28 19:58:02 MAW74656

-1 sp_Executesql a déjà été exécuté par le public. "Requiert l'appartenance au rôle public." http://msdn.microsoft.com/en-us/library/ms188001.aspx Le vrai problème est la rupture de chaîne de propriété lorsque vous utilisez sp_executesql Voir http://stackoverflow.com/questions/3815411 – gbn

Si vous avez durci votre base de données pour verrouiller le rôle public, alors @ MAW74656 est correct; par exemple, vous avez créé un rôle personnalisé pour remplacer le rôle public et supprimé tous les privilèges du public. Oui, cela va à l'encontre des exigences documentées, mais les systèmes d'analyse de renforcement de base de données comme AppDetective (via SQL Server STIGs) présentent le rôle public et son accès ouvert par défaut comme un risque majeur. – Draghon

... de plus, en citant le même article MSDN, "Les instructions Transact-SQL compilées dans le temps peuvent exposer des applications à des attaques malveillantes." Ceci est plus visible que l'instruction "Requiert l'appartenance au rôle public". – Draghon

Dans l'emballage proc vous pouvez utiliser EXECUTE AS OWNER ou EXECUTE AS SomeuserWithNoLogin

Cela va changer le contexte de connexion pour la durée de la procédure stockée qui comprend sp_executesql.

Si vous utilisez OWNER, cela fonctionnera car vous utilisez déjà le chaînage de propriété.
Si votre DBA (bonhomme!) Ne veut pas que vous exécutez en tant que dbo, alors configurez un utilisateur qui a pleine lecture mais aucun droit. EXECUTE AS <user> nécessite une entrée est sys.database_principals

Comme ceci:

CREATE USER SomeuserWithNoLogin WITH WITHOUT LOGIN 
EXEC sp_addrolemember 'db_datareader', 'SomeuserWithNoLogin'

Pour plus d'informations, voir EXECUTE AS Clause on MSDN et CREATE PROCEDURE

Source

2010-09-28 19:59:06 gbn

Autorisations lors de l'utilisation de "Execute sp_Executesql"

Répondre

Questions connexes