A Security Roadmap - Database Owner Rights in SQL Server 6.5
(Page 7 of 7 )
Database roles are not part of SQL Server 6.5. The permissions listed in the preceding sections belong only to the sa account and the dbo database account. The main reason SQL Server 6.5 allows multiple login accounts to share database user accounts is to allow multiple people to share the permissions granted only to the dbo user account. In Chapter 3, you will look at how this many-to-one mapping works, and then in Chapter 4 you will look at how SQL Server 7.0 and 2000 database roles offer a more manageable mechanism for permitting multiple users to perform common database operations.
Summary So far, I have just hit the highlights of SQL Server security. In general, there are three major points at which you must make significant decisions about how to authenticate users and authorize access:
- First, you must decide how you will authenticate server logins, mostly because Windows authentication offers some significant advantages in overall ease of management if you have a Windows-only network.
- Second, you must decide how users will gain access to the databases on your server. Once again, Windows authentication presents some advantages, but it also presents some challenges due to the fact that Windows NT groups can be users in the database.
- Third, you must decide how to grant permissions to database users. You can choose to grant permissions to individual users, Windows NT groups, and/or user-defined roles; or you can place users in the built-in database roles; or you can implement a combination of the two.
In many ways, determining how to assign permissions can be your most difficult security decision. In Chapters 3 and 4, you will use some examples to help you work through the rather complex interactions between database accounts and permissions and Windows authenticated logins.
After I lay the foundation in the next three chapters of how SQL Server’s security mechanisms work, I finish out the book with a look at network security, practical recommendations for securing applications, DTS, replication, and SQL Server CE. Just remember, you do not have to use every feature SQL Server offers; you can simplify matters by being selective. If you keep things simple, you are less likely to grant access that users should not have or deny access they should have. What you are looking for is that perfect solution in which users have exactly the permissions they need to do their jobs, and not one bit more or less. When you find it, you have succeeded in your mission to keep your data secure.
 This chapter is from SQL Server Security Distilled, by Morris Lewis (Apress, 2004, ISBN: 1590592190). Check it out at your favorite bookstore today. Buy this book now.
|
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 2 
