When setting up your application's database permissions, start with a custom role. Notice that I didn't say "account." Over time, accounts might change or the type of account (SQL Server or Windows) might change, but if you've tied your application permissions to a role, these details don't matter. Using a role means that when an account needs to change, you just add a new account to the role and remove the old account.
Sometimes, developers try to create one role for reading from and one role for writing to the database. This simple approach might sound good, but a better alternative is to create one role that has permissions to access only the stored procedures for your application. With only one role, if the account is compromised (either explicitly or implicitly), you can ensure that the only objects an intruder can reach are those that the application can legitimately access. Allowing direct access to the tables in your database means that if an account is breached, so is every column in the tables. When you allow access only through a stored procedure, the application might be able to insert information such as a credit card number, for example. But if SQL Server doesn't have a stored procedure to return a credit card number (and it shouldn't), intruders won't get a credit card number.
Keeping Up with the Bad Guys
No security solution is guaranteed, so you have to keep up with events that are occurring on your server. Set up alerts for specific errors that shouldn't be occurring, and if they occur repeatedly, investigate further so that you can see if someone's trying to leverage an application's vulnerability. In general, think of security in layers. I suggest that the next layer below what I covered here is how to protect the data once it's in your database. For example, encrypting important data such as credit card numbers is a good idea so that even if intruders find a path to your data, they don't also acquire the keys for unlocking it.
The SQL injection attack can be devastating when you consider how much data might be compromised. Don't wait for someone to drop your customer table or retrieve all the customer credit card numbers you have stored in your database. Take the steps to ensure that your application is secure from this attack.
End of Article
Prev. page
1
2
3
[4]
next page -->
