Microsoft® SQL Server® 2008 Bible

Chapter 49. Authenticating Principals

IN THIS CHAPTER

• Understanding SQL Server security

• Making sense of the many SQL logins

• Server-level security

• Server, database, and application roles

When I was a data systems technician in the Navy, I spent almost two years at Combat System Technical School Command (CSTSC) in Mare Island, California. It was good. My class was one of the last groups to be trained on the AN-UYK-7 computer. The CPU was a drawer with about 50 small cards populated with transistors. We learned to troubleshoot the CPU to the logic-gate level. It was very cool. We shared the island with the Crypto-tech school. The sailors in crypto school had it rough; they couldn't carry anything in or out of their school—no notes, no books, nothing. At least we could meet after hours in study groups. I was glad to be on the computer side of the command. Security has never thrilled me, but the Information Architecture Principle clearly states that information must be secured.

It's common practice to develop the database and then worry about security. While there's no point in applying security while the database design is in flux, the project benefits when you develop and implement the security plan sooner rather than later.

Security, like every other aspect of the database project, must be carefully designed, implemented, and tested. Because security may affect the execution of some procedures, it must be taken into account when the project code is being developed.

A simple security plan ...