Les autorisations lors de l'utilisation de l'option “Exécuter sp_Executesql”

J'ai une base de données dont l'accès est contrôlé par des procédures stockées. Le DBA voudrais éviter de donner aux utilisateurs directs accès en lecture/écriture aux tables sous-jacentes, ce que je peux comprendre. Ainsi, toutes les mise à jour et la sélection des données se fait via des procédures stockées. Fondamentalement, il a créé l'un rôle qui a les autorisations d'EXÉCUTION de toutes les procédures stockées dans la base de données et les utilisateurs de ce rôle.

Le problème est que l'une des procédures stockées de manière dynamique construit une Requête SQl et l'exécute via "Exécuter sp_Executesql". Sans entrer dans les détails de la requête est construite dynamiquement, car il modifie considérablement en fonction de nombreux paramètres d'entrée utilisateur. La procédure stockée en question est seulement une instruction SELECT sql cependant je trouve que juste de donner l'autorisation d'EXÉCUTION de la procédure stockée n'est pas assez. Les tables sous-jacentes référencé dans la procédure stockée qui rendent l'utilisation de l'option "Exécuter sp_Executesql" doivent avoir fait l'objet "datareader" l'accès ou de l'autre de la procédure stockée échoue.

Des idées sur comment remédier à cela? Je voulais vraiment restreindre l'accès aux tables à seulement procédures stockées, mais j'ai besoin de trouver un moyen de contourner les procédures stockées qui rendent l'utilisation de l'option "Exécuter sp_Executesq"l'. Merci.

Vous pouvez obtenir de meilleurs avdice serverfault. Mes conseils: - Parlez-en à l'administrateur de la base et expliquer la situation. Travailler avec eux pour obtenir les autorisations de droit.

OriginalL'auteur webworm | 2010-09-28

  1. 13

    Dans le wrapper proc vous pouvez utiliser EXECUTE AS OWNER ou EXECUTE AS SomeuserWithNoLogin

    Cela va changer l'identifiant de contexte pour la durée de la procédure stockée qui comprend sp_executesql.

    • Si vous utilisez PROPRIÉTAIRE, il va travailler parce que vous êtes déjà en utilisant le chaînage de propriété.
    • Si votre DBA (homme bon!) ne voulez-vous en tant que propriétaire de base de données, puis d'un utilisateur qui en a plein le lire, mais pas de droits. EXECUTE AS <user> requiert une entrée est sys.database_principals

    Comme ceci:

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

    Pour plus d'info, voir EXÉCUTION de l'article sur MSDN et CREATE PROCEDURE

    OriginalL'auteur gbn

  2. -3

    Le vrai problème est que sp_Executesql est dans la base de données master, pas nécessairement de la base de données de votre travail. Votre DBA a donner exécuter sp_Executesql l'autorisation de la procédure d'appel. Que toute personne qui a la permission d'appeler cette procédure sera en mesure d'exécuter le sp_Executesql.

    -1 sp_Executesql publique a déjà exécuter. "Nécessite l'adhésion au rôle public." msdn.microsoft.com/en-us/library/ms188001.aspx Le vrai problème est la propriété de chaînage des pauses lorsque vous utilisez sp_executesql Voir ce stackoverflow.com/questions/3815411
    Si vous avez trempé votre base de données pour verrouiller le rôle du public, alors @MAW74656 est correct; par exemple, vous avez créé un rôle personnalisé pour remplacer le rôle du public et supprimé tous les privilèges du public. Oui, cela va à l'encontre des exigences documentées relatives mais la base de données de durcissement des systèmes de lecture comme AppDetective (via SQL Server STIGs) présente le rôle du public et de ses valeurs par défaut de l'accès ouvert comme un risque majeur.
    ...d'ailleurs, en citant ce même article MSDN, "compilées à l'Exécution des instructions Transact-SQL peuvent exposer les applications contre les attaques malveillantes." C'est plus en évidence que le "Nécessite l'adhésion au rôle public".

    OriginalL'auteur MAW74656