July 5, 2013 at 10:11 am
We have a package with sensitive data so encryptWithUserKey, and then run in the SQL Agent using a proxy is the best option.
But, we want to use a specific proxy account,and dont want to create a proxy for the developers account.
Is it possible to set what account the package uses to EncryptWithUserKey?
July 5, 2013 at 10:47 am
winston Smith (7/5/2013)
We have a package with sensitive data so encryptWithUserKey, and then run in the SQL Agent using a proxy is the best option.But, we want to use a specific proxy account,and dont want to create a proxy for the developers account.
Is it possible to set what account the package uses to EncryptWithUserKey?
I would tend to use something other than EncryptSensitiveWithUserKey. I would probably more likely use EncryptSensitiveWithPassword or EncryptAllWithPassword. In general I try not to store ANYTHING sensitive in the package itself. This means that even if the EncryptSensitiveWithUserKey is set it won't actually do anything.
I would not want to have a developers account as a proxy. The effect of that would be to potentially give the developer elevated rights to production resources.
As far as whether you can tell what account was used to save the package I'm not sure you can KNOW but you might be able to see the creator name in the package properties. But that is the creator, NOT the last saved..
CEWII
July 5, 2013 at 11:07 am
I appreciate it might not be the best solution from your point of view, but forgetting if its good or bad, is the only way to assign a new owner to the package to open and save it under the proxy account credentials? its quite a bit of hassle to do that. would be much better if you could "encryptWithSpecifiedUserKey"
Thanks for the prompt response!
July 5, 2013 at 11:10 am
winston Smith (7/5/2013)
I appreciate it might not be the best solution from your point of view, but forgetting if its good or bad, is the only way to assign a new owner to the package to open and save it under the proxy account credentials? its quite a bit of hassle to do that. would be much better if you could "encryptWithSpecifiedUserKey"Thanks for the prompt response!
Yes, you have to open it as the correct user, fix the credentials that are now invalid, and then re-save. That's about it..
Honestly I would change the protection level and use a password which can then be stored in the job that runs it.. YMMV
CEWII
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply