Course Topics

Administering SQL Server 2012 Jump Start

01 | Install and Configure SQL Server

04 | Manage Data

02 | Maintain Instances and Databases

05 | Implement Security

03 | Performance Optimization and Troubleshooting

06 | High Availability Options

Click to edit Master subtitle style

05 | Security ImplementationGeorge Squillace | Senior Technical Trainer – New Horizons Great LakesRichard Currey | Senior Technical Trainer – New Horizons United

Module 5 Overview

• Server Logins and Server-level Roles

• Database Users and Database-level Roles

• Implementing Permissions

Topic: Server Logins and Server-level Roles

Topic: Server Logins and Server-level Roles• Security Scopes

• Authentication Modes

• Login Objects

• Server Roles and Server-level Permissions

Security Scopes

• Server / instance– Database

• Schema– Object

• Scope-specific permissions exist

• Permission statements– GRANT– REVOKE– DENY

Authentication Modes

• Two modes

• SQL logins are protected better by using password policies

• Set during installation and they can be changed later

• Switching requires a service restart

• Functionally only a registry key change

Login Objects

• Purpose

• Derived from– Windows

• Domain• Machine local

– SQL logins

• Administration tools– SSMS– CREATE / ALTER / DROP LOGIN– Options

Server Roles and Server-level Permissions

• Types of server-level roles– Fixed server roles– User-defined server roles

• Server-scoped permissions

• Administration tools– SSMS– sp_AddSrvRoleMember– CREATE / ALTER / DROP SERVER ROLE

DEMOImplementing Server-level Security

Topic: Database Users and Database-level Roles

Topic: Database Users and Database-level Roles• Database Users

• Database-level Roles

• Application Roles

• Contained Databases

Database Users

• Database users– Derived from logins

• Types of database-level roles– Fixed– User defined

• Application roles

• Database-scoped permissions

Database-level Roles

• Types of database-level roles– Fixed– User defined

• Database-scoped permissions

• Administration tools– SSMS– CREATE / ALTER / DROP ROLE– sp_AddRoleMember

Application Roles

• The purpose of an Application Role is toprotect against making connectionsto SQL Server outside of front-end application logic (using Excel or Access, for example)

• Instead an application calls an Application Rolethat the end-user is unaware of (and that is assigned database permissions)

• Administration tools– SSMS– CREATE / ALTER / DROP ROLE– sp_AddRoleMember– sp_SetAppRole and sp_UnSetAppRole

DEMOImplementing Database-level Security

Contained Databases

• A problem with moving and restoring databases is that they have dependencies on login and other objects

• A possible solution is a contained database

• Requires a server-level and database-level option– sp_Configure N’Contained Database Authentication’– ALTER DATABASE DBx Set Containment = Partial

• Applicable principals– Windows user– Windows group– SQL login

DEMOCreating Users for a Specific Database (Contained Database)

Topic: Implementing Permissions

Topic: Implementing Permissions

• Object Permissions

• Code and Module Permissions

• Applying Permissions

• Permission Management Strategies

“Principals are assigned Permissions to Securables.”

Object Permissions

• Applies to tables, views and table-valued user-defined functions

• Primary permissions– ALTER– CONTROL– SELECT, INSERT, UPDATE, DELETE– VIEW DEFINITION

Code and Module Permissions

• Applies to scalar user-defined functions and stored procedures

• Primary permissions– ALTER– CONTROL– EXECUTE– VIEW DEFINITION

Applying Permissions

• SSMS– Begin with a principal– Begin with a securable

• T-SQL statements– GRANT– REVOKE– DENY• Security model anomaly (prior to SQL Server 2012)

– Column-level GRANT override Table-level DENY

Permission Management Strategies

• Various strategies– Aim for “double

abstraction”

• Leverage roles– Roles can be nested

• Leverage schemas

DEMOImplementing a Permission Strategy by Assigning a Role Permission to a Schema

©2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, Office, Azure, System Center, Dynamics and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.