Why should an application not use the sa account

My first question ever, please be gentle. I understand that the sa account enables complete control over a SQL Server and all the databases, users, permissions etc.

I have an absolute belief that applications should not use the sa password without a perfected, business person focused reason why. Answers to This Question include a lot of my reasoning for an IT focused discussion

I am being forced into accepting a new service management system that WILL NOT work unless it uses the sa password. I never had time to work out why when setting up an evaluation but the server team tried to install it to use a fixed role I had set up incorporating db_creater and other permissions I thought it would require. which failed. I then let the server team install with the sa account but run under an account in the dbo role for its database but that failed too. Grumpily I tried to get it to run with an account in the sysadmin role but even that failed and not with useful error messages that enabled me to work out what was going on without spending more time than I had available. It will only work with the sa account and the password stored in clear text in the config file.

When I queried this and the server team talked to the vendor they got the worrying answer of 'What's the problem with that?' and then 'well we can look at scrambling the password' scrambling ffs

I know that there are ways and means to restrict access to the file but it is just another weakness in the security in my opinion

Anyway, My question is, could someone point me at some documentation that I can use to explain to the business the reason why this is a bad thing and should be a big no no. I work in a field that means that I need to take security seriously and have been struggling to make the business understand and ultimately may be out-ranked anyway but I need to try.

It depends on your business, but the main thing in most cases is to make sure it is not seen as an IT issue. It is a security issue and while the two overlap massively business peopel are more likely to listen if you say "security" than if you are just "moaning about general IT stuff".

Do you work with any clients that have security requirements? That is a good place to start. If we ran an app with sa level access, or just app that didn't properly secure its credentials even if not using priveleged access (we strongly prefer Windows Integrated rather than stored user/pass where possible), and we were subject to a security audit, that audit would fail and we would risk losing customers and/or having to give money back as to our groups's clients (banking organisations in the case of the product I work on mostly, other parts of the group deal with the police and health authorities and so forth) security is part of our offering being fit for purpose. Business people will understand the severity of that potential threat even if they usually pay no more than lip service to IT recommendations.

Even ignoring client imposed requirements, if you strive to meet various industry standard security standards then again this sort of application authentication is going to fail you in the face of an audit as it is so far from best practise as to be something generally considered to be on the "simply shouldn't be done" list. Make clear to your business descision makers that security is an important part of the application, and the fact that this vendor does not seem to be aware of (or at least appropriately concerned about) makes you have doubts about what else they might not capable of dealing with: knowing about DB security best practise is (well, should be) part of their job and imlpementing it is not difficult.

Also point out that you (the purchaser) should be dictating reasonable security requirements to the vendor, not the other way around. It is your data, so they are not qualified to state what is considered secure enough.

StackExchange Database Administrators Q#39124, answer score: 22