Restrict the usage of a SQL Server Authenticated Application Id

Restrictions Ahead
Restrictions Ahead
SQL Server login ids may not be the most secure thing in the world but they are likely to be around for quite a while and one of the more common uses of them is as an application id. An application uses a SQL Server id to connect to SQL and then controls its own security internally. The problem comes in when developers decide “Hey, I have the password to the app id, it has way more permissions in the database than I do. I’ll just use it.” So why is that a problem? Well, here are a few examples:

  • Clear text passwords. There are ways to send an encrypted password to SQL but if the developer is doing something like this they probably aren’t using them.
  • Lack of clear accountability. There is no way to know for certain who is using the id. It could be anyone.
  • Permissions are controlled for a reason. This developer is using permissions not properly granted to them, possibly causing a data breach through a lack of understanding of why these procedures are in place. Heck, they could be the data breach themselves. It wouldn’t be the first time an employee has stolen data.
  • Avoiding being accused of stealing data. Guess what, if you have access to this account and data is stolen using it, you are a suspect. No one want’s that unless it’s unavoidable right?
  • Not to mention that SQL Authentication is just less secure to begin with.

Anyone of these would cause you to fail a security audit. All of them together? Not good.

So how do we fix it?

Continue reading on

Continue reading on

(1 vote. Average 5 of 5)
Leave a reply

Your email address will not be published. Required fields are marked *