Can you protect linked servers from sa

We have a third-party vendor setting up software on a server. They have full access to that server and the sql-server on it with the sa account. We would like to set up a linked server so that a trigger can update data on a remote machine. Does access to the sa account necessarily mean that they have full access to the linked server or is there a way to protect yourself from sa?

EDIT: We wanted to give them full control of the server because we want them to have full responsibility. It takes the blame off us when it stops working. "hey, we didn't touch it, you fix it, you have full permissions". That way, they can do whatever they need to to get their software working, but it's in a sand boxed environment. We just need a trigger to get the final records out of their database and insert into our production database. That requires permissions we don't want to give them. The question was meant to ask if there was a way to save the password in that sand boxed environm开发者_如何学Pythonent under there noses. so to speak.

Never give anyone access to the SA account.

Instead, give them a named user account even if it still has full system level privileges.

Second, the linked server is going to be set up with a named user that is allowed to impersonate a named user on the other end. If they have an account with full privileges on the first server then they will be able to get to the other. It's as simple as changing the password of the user account that is granted access to the remote server.

Which brings us to another item: Never give an external entity full rights to anything unless they OWN the box. If, for some weird reason, you have no other choice then you should find an alternate way of transferring the data from this server to your production server.

One way would be to set up SSIS packages that drop the data in a directory the remote server will monitor for pickup. Sure this adds a bit more complexity, but in the end it will mean your stuff is still secure.

Finally, Linked Servers are notorious for being flaky in general. You are much better off finding a different way to transfer the data... Such as using the SSIS method.

You can set up the linked server to use a named user -- your third party contractor will still be able to see "the other end" of the link, but only with the rights granted to that named user.