I have a database for a web application that is home to some personal information about my users.
What should I do to make sure the data is secure?
Encrypting the data makes sense, of course... but what about stopping somebody from getting on the machine to begin with?
What do I do about the developers that need access to the data, to make fixes, etc...?
Is there a document or best practice site that I can use as a guide?
Well the developers should probably do all their work on a development database that doesn't contain sensitive information to start with.
You need to pratice standard security for a windows server. A good place to start is to use integrated logins rather that SQL logins.
You will need to study the books on-line. You can give some users read-only access. Others can be denied access to sensitive tables.
Depending on the type of data I'm not sure that encryption is necessary providing you secure access to the system and the database itself. All of our production database servers are behind a firewall. Only systems that are on the administrative network are allowed access through the firewall and then only on specific, required ports. Database servers don't host web servers.
Access to the database servers themselves is strictly limited to DBAs and platform support personnel. They use administrative logins, not their personal login ids. That way if their personal account is compromised the database servers aren't.
For web servers only web admins and platform support have access (I happen to wear two hats, web developer and web admin, although that is rare in our organization).
Developers have access to shares where they can publish their application, usually coordinated with the web admin for any setup/configuration. Some senior developers are given administrator access to databases in order to create/modify schemas.
Usually, what happens is you develop using a locally installed database server, upload code to QA servers that have a little looser access policy, but are only accessible from company networks, then have the DBAs copy the database schema and roles to production and publish your app to the production web server.
Web apps are often configured to run under limited credential service accounts which have read/write, but not admin, access to the database. I typically encrypt any part of my web.config that contains connection information as well.
The general idea is to give enough access to get your job done without too much bother, but limit access to the minimum required.
Oh. And no "real" data on development or QA servers.
[EDIT] We don't keep SSNs or credit card numbers. If you do, you'll need to be even more careful. Most of my apps do access logging, some are required to due to HIPPA, but I find that it is a good practice for just about anything meaningful
I would use Active Directory to control access to SQL Server or any network resource. By grouping the users and applying security to the group, it will make it so much easier to make changes in the future.
Here is a guide from Microsoft on SQL Server 2005 Security Best Practices: http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/SQL2005SecBestPract.doc *Note: it downloads a Word document, so you will need MS Word or the MS Word viewer
This document has a lot of detail so you may want to grab some coffee first :).
However, I agree with the others, active development shouldn't happen against production data. We currently use a process of cleaning production data before it gets to the QA or Dev environments.
Another option we explored is developing a solution to generate data for Dev and QA.
Here in the UK we have legislation known as the Data Protection Act. If you worked for a UK company I would advise you to speak to your company's 'data controller' (being the individual whom the Information Commissioner's Office can pursue legally in instances of non-compliance) and they will be able to furnish you with a definitive answer about what 'secure' means as regards the data in question, probably enshrined in a written company policy.
If you are in the US I'd guess your corporation might have a bunch of highly paid lawyers who will be able to similarly give a definitive answer :)
I'm no legal expert but would suggest that obfuscating data does not make it fit for any purposes other than that for which it was obtained e.g. integration testing by developers using obfuscated 'real life' data is probably a no-no.