What can securables do in 2005/2008 that you couldn't in 2000?

dsrnu
dsrnu used Ask the Experts™
on
SQL Server 2000 had permissions you can use to secure certain tasks so then what can you do with securables in 2005/2008 that you couldn't do before?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Securables are the resources to which the SQL Server Database Engine authorization system regulates access. Some securables can be contained within others, creating nested hierarchies called "scopes" that can themselves be secured.
-- http://technet.microsoft.com/en-us/library/ms190401.aspx

So its basically for controlling the access in more organized manner.
Senior Data Architect
Commented:
Are you just asking in what ways the security scopes are handled differently in SQL 2000 vs the newer versions, or maybe what new objects are available to have security applied to them?

If so, I don't believe there are any major differences here, as you can still secure the same objects and schemas, as you could in SQL 2000. I can't think of any new securables offhand, but SQL Server applies security to everything it does, and any task you're allowed to perform has certain access rights associated with it. If it's possible, it can granted or revoked for any user of the system.

Do you have something in particular you're asking about?

Author

Commented:
So what can securables do taht you couldn't before in 2000 then?
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Ryan McCauleySenior Data Architect
Commented:
I'm still not sure I understand your question, but I don't believe there's anything new that you can do. Are you just looking for a comparison of the versions, or do you have something particular in mind that you're asking about?
This sounds like an interview or test question, but I'll bite anyway.  In SQL Server 2000, you could assign permissions on SELECT, UPDATE, DELETE, CREATE, etc.  SQL Server 2005 introduced more granular security and allowed  things like CONTROL, ALTER, IMPERSONATE, TAKE OWNERSHIP, etc.  Here is the Microsoft reference.

http://msdn.microsoft.com/en-us/library/ms191291.aspx

Greg



Author

Commented:
Greg, not an interview or test question. =) Just trying to grasp the key differences between SQL Server 2000 and SQL Server 2005/2008 as it relates to secuirty (securables, objects, and permissions).

I'm taking a look at the different permissiong granted to users between SQL Server 2000 and SQL Server 2005/2008.. so then, are you saying that you cannot do something like CONTROL SERVER in 2000 but you can in 2005/2008?

Author

Commented:
Also--what would be an example of something more granular than GRANT SELECT on tables?
Top Expert 2004
Commented:
First, securables in MSSQL2005 and permissions in MSSQL2000 are not comparable.  You grant/deny *permissions* to *securables*.  The main difference is the expansion of the number of items that can be permitted in 2005+.  

MSSQL2000 allowed permissions for a standard selection of things.  You could assign permissions to users for tables, views, functions, and so on.  In 2005+, that selection has been very much globalized.  In 2000, "securables" were mainly just "database objects".  The introduction of the new term in 2005+ expands that collection to virtually anything in the database service.  Since the structure of the underlying engines has moved away from procedural and towards object-oriented, everything in it is now an object.  As such, every object can be secured with permissions.  Also, this new structure allows for privilege chaining, which is akin to the "EXECUTE AS" concept from stored procedures.  Chaining, though, can apply to any securable object on the server, or even across servers.

So what can be done with this new system?  Well, it sets up the same kind of security mechanism one finds in Active Directory.  You can create mini-fiefdoms governed by delegated managerial accounts, for example, that do not have access to system- or server-wide abilities.  In 2000, if you wanted someone to manage security for a database, you made them part of the db_securityadmin role.  But suppose you only wanted them to manage the Sales groups of user accounts.  In 2005, you can quickly create a group of database users, and grant your manager full access to manage just that securable (the group), and nothing else.

The system lends itself towards a much more granular style of security management.  Where the older security system is a hammer pounding things into shape, the new one is an etching tool allowing you to control the fine details.

Author

Commented:
great explanations!!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial