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
la 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

Réponses:

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
la 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
la 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