SQL Server EXECUTE AS trouble

13

Je manque quelque chose en essayant d'utiliser ma procédure stockée EXECUTE AS. La procédure stockée lit les données source_db, les agrège et stocke le résultat target_db.

Le sp lui-même est dedans target_db. J'ai une connexion dédiée et la mappe aux utilisateurs à la fois source_dbet target_dbpour le propriétaire de sp (donc il y a un utilisateur app_agentdans source_dbet target_dbpour la connexion app_agent).

Si je me connecte en tant que app_agentet que j'exécute

EXEC target_db.app_agent_schema.import_data

tout fonctionne bien. Mais si je change

ALTER PROCEDURE app_agent_schema.import_data WITH EXECUTE AS OWNER` (or `AS SELF`)

et essayez de l'exécuter, il lance

Le principal du serveur "app_agent" n'est pas en mesure d'accéder à la base de données "source_db" dans le contexte de sécurité actuel.

J'utilise SQL Server 2008.

Quelqu'un pourrait-il signaler mon erreur?

Merci

Mise à jour Après avoir fait quelques recherches, j'ai trouvé que cela ALTER DATABASE target_db SET TRUSTWORTHY ONrésout le problème, mais cela ne semble pas être la bonne solution pour moi ...

sql-server-2008 security

— a1ex07
source

1

Je pense que la réponse consiste à utiliser l' option de chaîne de propriété de bases de données croisées de niveau base de données . J'ai pu reproduire l'erreur dans votre scénario, mais il n'y a pas suffisamment de détails pour savoir si je l'ai reproduite exactement ... l'option CDOC n'a pas fonctionné pour moi, mais essayez-la et voyez si cela le fait.

— Jon Seigel

24

Ceci est expliqué dans Extension de l'emprunt d'identité de base de données en utilisant EXECUTE AS . Le contexte EXECUTE AS n'est approuvé que dans la base de données actuelle et lui permettre de se propager à d'autres bases de données est une escalade du vecteur d'attaque de privilège.

Il existe deux solutions, toutes deux décrites dans l'article lié ci-dessus:

le plus facile est de marquer la base de données FIABLE: ALTER DATABASE [source_db] SET TRUSTWORTHY ON;. Bien que facile, est aussi dangereuse car elle rend la dbod' source_dbun de facto sysadmin.
le plus sûr est d'utiliser la signature de code, voir Appeler une procédure dans une autre base de données pour un exemple. C'est plus complexe, mais c'est une sécurité 100% buletproff.

— Remus Rusanu
source

0

Quel utilisateur exécute la commande ALTER PROCEDURE? Il peut avoir défini le niveau d'accès Propriétaire (auto) à cet utilisateur, pas celui que vous vouliez.

— Ciel
source

Le même utilisateur qui a créé la procédure ( app_agent). Si j'ai une procédure créée par app_agentsans execute as owner/self, connectez-vous en tant que app_agent, SP s'exécute correctement. Si j'ajoute EXECUTE AS SELF(encore une fois, le même utilisateur) et que app_agentje me connecte même en tant que , je reçois...is not able to access the database...

— a1ex07