• SQLBOT (1/11/2009)


    SA can enable xp_cmdshell, so I don't get your point here.

    I like what you're saying and it's worth noting that I think all SA access for vendors should be kept in check... sometimes it can't be. For me personally it's never worth the risk to multi-instance a machine if one of the instances has a user with SA.... ever.

    My line of thinking is that if they require SA, I'm not going to bend over backward, but rather cut a new VM, wash my hands and let the infosec and OS teams monitor them like they do all other production systems.

    ~BOT

    If that is an acceptable trade off for you and your company, and it works for you, then it is what it is. In SQL 2008, you can set a policy on the server that prevents enabling xp_cmdshell. Even if they do enable xp_cmdshell, if you separate Service accounts, they only get access to the level of priviledge of the service account, so the risk is minimum if you configure your service accounts properly.

    For my company, there is no way that $5K per CPU license and the extra resources for a SQL Instance for one database does not make sense, especially in the tougher economic times we face, and I don't work for a small company. Any place that I can save/cut costs, is well worth it, especially when it requires less than a few hours of work forcing a software vendor to do what they should have done responsibly in the first place.

    Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
    My Blog | Twitter | MVP Profile
    Training | Consulting | Become a SQLskills Insider
    Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]