Despite it being such an obvious security problem, developers still use the sa login, or assign sysadmin privileges to their Windows login, during their development work. Some take rather belligerent stance on this (“it’s my server; it’s not exposed to the outside world. What’s your problem?!”), but it seems to me that the majority are well aware that it’s a bad practice…and yet persist with it anyway. The use of logins with god-like powers can easily spill over to unit-tests, and even through to user-acceptance testing.

Often, when an application moves into production, it may, depending on the nature of the data that is held, need to conform to a security policy that uses carefully configured access-control techniques, to comply with current legislation. It is often at that point, when sysadmin superpowers can no longer be assigned to logins, that certain features simply stop working! It’s often possible to retro-fit a security design into the database, or to reconfigure the security credentials to avoid using sa, but in some cases, especially with third-party applications, it’s very difficult.

Ultimately, the business needs the application to work. The quickest solution to get the application into production is often to grant sysadmin privileges to the application login, in the production environment, and hope that the auditors don’t notice. On top of this of course, there are the various direct user logins, for reporting and so on, which often get elevated to sysadmin privileges and then quietly forgotten. The consequences for the security and support of the system are obvious, and too painful for the more sensitive DBA to read.

How can this happen? My own view is that, in the typical development team, all the pressure is on hitting measurable targets, and a robust security design isn’t easily measured. So often, a casual attitude to access-control in the development team spills over into the design of the application, and proper testing of testing of authentication and authorization is often completely overlooked. Database security isn’t a fashionable topic either: it is to database development what washing up is to cookery but, likewise, the cost of its neglect can be painful.

Cheers,

Tony.