1. Overview of Azure Data services
9/10/2018 9:18 AM
Overview of Azure Data services
Module 16
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

2. Module Agenda Securing the database Managing users
9/10/2018 9:18 AM
Module Agenda
Securing the database
Managing users
Understanding Privileges
Managing roles
The SQL Server Migration Assistant (SSMA), Microsoft Assessment and Planning Toolkit (MAP) tool, and SQL Server Integration Services (SSIS) combined with Oracle client drivers (and others) can be used in support of the following aspects of an Oracle or SAP migration:
Migration process & tooling
Data deployment
Cloud migration
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

3. Lesson 1
Securing the database

4. Lesson 1: Securing the database
8: Data protection and security
Lesson 1: Securing the database
Privileges and roles
Auditing
Encryption
Always Encrypted (2016)
Dynamic Data Masking (2016)
Other security improvements in SQL Server 2016

5. Layers of protection for your data
9/10/2018 9:18 AM
Layers of protection for your data
Layer
Features
Application
Row-level Security
Data Masking
Parameterized Queries
Database Network
Always Encrypted
Connection Encryption
AAD Authentication
Firewall
Auditing
Database
Database Roles
Permissions
Cell-Level Encryption
Stored Procedures
Thread Detection (*)
Impersonation
Host
Transparent Data Encryption
Application
Network
Database
Host
User access
Application Protections – These features protect data from people with access to the application (e.g. application user)
Database Network Protections – These features protect data from people with access to the data network (e.g. Developer, DBA)
Database Protections – These features protect data from people with access to the database (e.g. DBA, BI user)
Database Host Protections – These features protect data from people with access to the database host (e.g. OS administrator)
(*) Thread Detection applies only to Azure SQL Database
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

6. 40074A
8: Data protection and security
Database security
Security is implemented in both database management systems using logins and privileges
Users classified as:
Schema owners (SQL Server database object owners)
Application users
Administrative users
User authentication can be achieved through the operating system login, database login, or contained database
SQL Server security depends on Windows security for features such as password expiration

7. Privileges and roles Oracle and SQL Server both contain: Roles group
8: Data protection and security
Privileges and roles
Oracle and SQL Server both contain:
System-level privileges to perform actions against any object in the database
Object-level privileges to perform actions against specific schema objects
Roles group
System-level and object-level privileges
SQL Server fixed and user-defined roles for the server and database
Application roles in SQL Server:
Implemented using application logic
Password protected

8. Row-level security
Protect data privacy by ensuring the right access across rows
Fine-grained access control over specific rows in a database table
Help prevent unauthorized access when multiple users share the same tables, or to implement connection filtering in multitenant applications
Administer via SQL Server Management Studio or SQL Server Data Tools
Enforcement logic inside the database and schema bound to the table.
Customer 1
Customer 2
Customer 3
SQL Database
Row-Level Security (RLS) simplifies the design and coding of security in your application. RLS enables you to implement restrictions on data row access. For example ensuring that workers can access only those data rows that are pertinent to their department, or restricting a customer's data access to only the data relevant to their company.
The access restriction logic is located in the database tier rather than away from the data in another application tier. The database system applies the access restrictions every time that data access is attempted from any tier. This makes your security system more reliable and robust by reducing the surface area of your security system.
Implement RLS by using the CREATE SECURITY POLICY Transact-SQL statement, and predicates created as inline table valued functions.
Limitations during the preview:
RLS is incompatible with database export using Data Tier Application Framework (DACFx). You must drop all RLS policies before exporting.
Security policies cannot target views.
Certain query patterns using OR logic can trigger un-optimized table scans, decreasing query performance.
No syntax highlighting in SQL Server tools.

9. Demo
Provide instance security

10. Demo: Provide instance security
8: Data protection and security
Demo: Provide instance security
Based on prior demo in Module 8
Create a Windows user account
Associate a SQL Server login with the Windows user account
Demonstration Steps
Click Start → Administrative Tools → Computer Management.
Expand the Local Users and Groups folder in the tree view on the left. Click the Users folder, and then right-click in the right pane and select New User.
Enter Demo in the User Name, Full Name, and Description boxes.
Enter demo in the Password and Confirm Password boxes.
Clear the User Must Change Password at Next Login checkbox.
Select the Password Never Expires.
Click Create, and then click Close.
In the Object Explorer, expand the INST01 instance node.
Expand Security, and then expand the Logins folders.
Right-click the Logins folder and select New Login.
Click the Search button and enter Demo in the dialog window, click Check Names, and then click OK.
Change the Default Database menu to show the AdventureWorks2012 database.
Select the User Mapping page in the Login – new dialog.
Click the checkbox in the Map column next to the AdventureWorks2012 database in the upper window, and check the db_datareader Database Role in the lower window. If the db_owner role is checked, ignore it. It’s the result of a Management Studio bug, and it’s not really selected.
Click OK. You’ve now created a Windows user, and granted that user read access to the AdventureWorks2012 database.

11. Auditing Auditing facilitates database activity monitoring
8: Data protection and security
Auditing
Auditing facilitates database activity monitoring
Monitoring statements, privileges, or objects
Similar to Oracle Audit Vault for DDL and DML statements
All actions (DDL and DML) are auditable in SQL Server
DDL triggers and notifications can aid in auditing
SQL Server server-level auditing is resilient, available in all editions, and provides T-SQL call stack frame info
SQL Server supports user-defined audit groups and audit filtering
Reference: SQL Server Audit (Database Engine) -
A key part of any data security strategy is the ability to track who has accessed, or attempted to access, your data. This provides the ability to detect unauthorized access attempts or, if necessary, to piece together the actions of malicious insiders who misused their legitimate access. Furthermore, a rich and robust tracking capability can provide oversight of sensitive configuration changes made by administrators.
Such considerations are ever more relevant in today’s information economy. Data is collected, stored, used, and misused at an ever increasing rate. Governments and private sector organizations around the world are responding to this by establishing various compliance regimes to improve the stewardship of data by those who hold it. A few of the most widely known examples include:
European Union Data Protection Directive, a strict data protection policy with implications across the EU and the global economy.
HIPAA, or Health Insurance Portability and Accountability Act, part of United States law
Sarbanes-Oxley, part of United States law governing corporations.
Payment Card Industry Data Security Standard, mandated by major credit card companies, with worldwide implications
This feature allows database administrators to capture auditing information such as events at the server level and at the database level. By using this feature, you can answer questions such as “who changed configuration settings on my server and when the change was made”, “who modified an important table in my database and when that table was modified” etc.
SQL Server Audit is a better alternative for auditing compared to SQL traces because it allows pre-filtering the events based on objects and principals that you are interested in auditing. Moreover, with SQL Server Audits, auditing of activity of users/roles/groups on database objects can be restricted down to the table level. That means that you can target SQL Server Audit to track specific activities of a user or users down to the individual table level. For example, SQL Server Audit allows a record to be made of all the UPDATEs to the Payroll table by DBO. SQL Server audit also allows storing the audit events in Application or Security events logs, which are much secure compared to storing the audit data directly into trace files.
The SQL Server Audit feature is built on top of Extended Events to leverage the performance benefits and provide both asynchronous and synchronous write capabilities (by default, SQL Server Audit uses the asynchronous event model). Auditing with SQL traces can have a significant performance impact. If all audit counters are turned on for all objects, the performance impact could be high. Also , if you consider using traces for your auditing needs, you can’t use fine grained auditing targeted on specific objects and specific logins.
One thing to note is that the Audit event is a protected type of Extended Event so the CREATE/ALTER/DROP SESSION EVENT commands cannot be used to manipulate SQL Server Audit directly
All editions of SQL Server support server level audits. Database level auditing is limited to Enterprise, Developer, and Evaluation editions
Actions on a server audit (CREATE, ALTER, or DROP) require the ALTER ANY SERVER AUDIT permission, which is covered by the CONTROL SERVER permission.

12. Encryption Encryption hierarchy Transparent Data Encryption
SQL Server and database encryption keys
SQL Server 2016 includes two new features:
Always Encrypted
Dynamic Data Masking
Resource:
From “Encryption Hierarchy” -
SQL Server encrypts data with a hierarchical encryption and key management infrastructure. Each layer encrypts the layer below it by using a combination of certificates, asymmetric keys, and symmetric keys. Asymmetric keys and symmetric keys can be stored outside of SQL Server in an Extensible Key Management (EKM) module.
The illustration shows that each layer of the encryption hierarchy encrypts the layer beneath it, and displays the most common encryption configurations. The access to the start of the hierarchy is usually protected by a password.
Keep in mind the following concepts:
For best performance, encrypt data using symmetric keys instead of certificates or asymmetric keys.
Database master keys are protected by the Service Master Key. The Service Master Key is created by SQL Server setup and is encrypted with the Windows Data Protection API (DPAPI).
Other encryption hierarchies stacking additional layers are possible.
An Extensible Key Management (EKM) module holds symmetric or asymmetric keys outside of SQL Server.
Transparent Data Encryption (TDE) must use a symmetric key called the database encryption key which is protected by either a certificate protected by the database master key of the master database, or by an asymmetric key stored in an EKM.
The Service Master Key and all Database Master Keys are symmetric keys.

13. Always Encrypted
Help protect data at rest and in motion, on-premises & cloud
Trusted
Apps
SELECT Name FROM Patients WHERE
@SSN=' '
SQL Server
SELECT Name FROM Patients WHERE
@SSN=0x7ff654ae6d
Client side
Enhanced ADO.NET
Library
dbo.Patients
Jane Doe
Name
SSN
USA
Country
Jim Gray
John Smith
Query
Result Set
Jim Gray
Name
Jane Doe
1x7fg655se2e
SSN
USA
Country
0x7ff654ae6d
John Smith
0y8fj754ea2c
dbo.Patients
Column
Master Key
Column Encryption Key
Result Set
Jim Gray
Name
Source:
Always Encrypted is a feature designed to protect sensitive data, such as credit card numbers or national identification numbers (e.g. U.S. social security numbers), stored in SQL Server databases. Always Encrypted allows clients to encrypt sensitive data inside client applications and never reveal the encryption keys to SQL Server. As a result, Always Encrypted provides a separation between those who own the data (and can view it) and those who manage the data (but should have no access). By ensuring on-premises database administrators, cloud database operators, or other high-privileged, but unauthorized users, cannot access the encrypted data, Always Encrypted enables customers to confidently store sensitive data outside of their direct control. This allows organizations to encrypt data at rest and in use for storage in Azure, to enable delegation of on-premises database administration to third parties, or to reduce security clearance requirements for their own DBA staff.
Always Encrypted makes encryption transparent to applications. An Always Encrypted-enabled driver installed on the client computer achieves this by automatically encrypting and decrypting sensitive data in the SQL Server client application. The driver encrypts the data in sensitive columns before passing the data to SQL Server, and automatically rewrites queries so that the semantics to the application are preserved. Similarly, the driver transparently decrypts data, stored in encrypted database columns, contained in query results.
ciphertext
dbo.Patients
Jane Doe
Name
1x7fg655se2e
SSN
USA
Jim Gray
0x7ff654ae6d
John Smith
0y8fj754ea2c
Country

14. Dynamic Data Masking
Prevent the abuse of sensitive data by hiding it from users
Configuration made easy in the new Azure portal
Policy-driven at the table and column level, for a defined set of users
Data masking applied in real-time to query results based on policy
Multiple masking functions available (e.g. full, partial) for various sensitive data categories (e.g. Credit Card Numbers, SSN, etc.)
Table.CreditCardNo
Real-time data masking; partial masking
SQL Database
SQL Server 2016
Source:
Dynamic data masking limits sensitive data exposure by masking it to non-privileged users. Dynamic data masking helps prevent unauthorized access to sensitive data by enabling customers to designate how much of the sensitive data to reveal with minimal impact on the application layer. It’s a policy-based security feature that hides the sensitive data in the result set of a query over designated database fields, while the data in the database is not changed. Dynamic data masking is easy to use with existing applications, since masking rules are applied in the query results, and there is no need to modify existing queries.
For example, a call center support person may identify callers by several digits of their social security number or credit card number, but those data items should not be fully exposed to the support person. A developer can define a masking rule to be applied to each query result that masks all but the last four digits of any social security number or credit card number in the result set. For another example, by using the appropriate data mask to protect personally identifiable information (PII) data, a developer can query production environments for troubleshooting purposes without violating compliance regulations.
Dynamic data masking limits the exposure of sensitive data and prevents accidental viewing by engineers that access directly databases for troubleshooting purposes or non-privileged application users. Dynamic data masking doesn’t aim to prevent privileged database users from connecting directly to the database and running exhaustive queries that expose pieces of the sensitive data. Dynamic data masking is complimentary to other SQL Server security features (auditing, encryption, row level security…) and it is highly recommended to enable them in addition in order to protect better the sensitive data in the database.
Since data is masked just before being returned to the user, changing the data type to an unmasked type will return unmasked data.
Dynamic data masking is available in SQL Server 2016 Community Technology Preview 2 (CTP2). However, to enable dynamic data masking, you must use trace flags 209 and 219. For Azure SQL Database, see Get started with SQL Database Dynamic Data Masking (Azure Preview portal).

15. Other security enhancements
Audit success/failure of database operations
Enhanced auditing for OLTP with ability to track history of record changes
Transparent Data Encryption support for storage of In- memory OLTP Tables
Backup encryption now supported with compression
Source:

16. Resources SQL Server Audit (Database Engine)
SQL Server and Database Encryption Keys (Database Engine)
Always Encrypted
Dynamic Data Masking
SQL Server Security Blog

17. Lesson 2
Managing users

18. Lesson 2: Managing users
8: Data protection and security
Lesson 2: Managing users
Creating login accounts
Demo: Creating logins and users
Contained database authentication

19. Understanding accounts
8: Data protection and security
Understanding accounts
A user name is database system wide in Oracle, but SQL Server uses login accounts to access the instance and user accounts for individual databases (Oracle 12c pluggable databases can have their own users)
Oracle user names and SQL Server logins can be operating system authenticated or database authenticated; SQL Server logins can be authenticated by the network domain
User authentication can be achieved with a contained database without logins as of SQL Server 2012
In SQL Server, a user account has to be created in every database that a login needs access to and can be named differently from the login name

20. Creating login accounts
8: Data protection and security
Creating login accounts
Two methods of authentication for SQL Server logins:
Windows authentication
SQL Server authentication
In SQL Server, a user account has to be created in every database that a login needs access to and can be named differently from the login name
Windows Authentication: SQL Server Windows authentication relies on the security mechanism of the Microsoft Windows operating system to validate login connections. Any user who has been authenticated by the trusted Windows domain, regardless of the location or computer, can connect to a SQL Server instance without providing a separate login and password.
Logins based on Windows authentication can be added to the SQL Server instance using the following T- SQL statement:
CREATE LOGIN login_name FROM WINDOWS [WITH windows_options]
In this statement the login_name is of the form domain_name\domain_login_name.
The optional Windows_options can be:
DEFAULT_DATABASE = database
| DEFAULT_LANGUAGE = language
SQL Server Authentication: A login using the SQL Server authentication method specifying the pre- requisite login account and password can be defined by using the following CREATE LOGIN T-SQL statement:
CREATE LOGIN login_name { WITH < option_list1 >}
The option_list1 can include any or all of the following:
PASSWORD = ' password ' [ HASHED ] [ MUST_CHANGE ]
[ , option_list2 [ ,... ] ]

21. Demo
Creating logins and users

22. Demo: Creating logins and users
USE master; GO
IF EXISTS(SELECT *
FROM sys.server_principals
WHERE name = 'demo2')
DROP LOGIN demo2;
CREATE LOGIN demo2
WITH PASSWORD = 'demo123*',
DEFAULT_DATABASE = AdventureWorks2016,
DEFAULT_LANGUAGE = us_english;
Create a Windows login account
Create a SQL Server login and user account
Create logins using T-SQL
Includes setting password policy for login

23. Default schema for Windows groups
Default Schema = schema1
Assign default schema to windows group
Eases administration
Avoids implicit schema creation
Reduces chances of wrong schema used in queries
Group1

24. (Contained user Alice exists)
Contained databases
Allow authentication without Server Logins
SQL users with passwords
Windows authentication without Login
Easier development for some applications
Tightly scoped security boundary
Off by default
Can be managed by Login Triggers
No login mapping needed for Availability Groups
User=Alice; Pwd; IC=CDB
Contained User
(Contained user Alice exists)
Contained Databases -
A contained database is a database that is isolated from other databases and from the instance of SQL Server that hosts the database. SQL Server 2016 helps user to isolate their database from the instance in 4 ways.
Much of the metadata that describes a database is maintained in the database. (In addition to, or instead of, maintaining metadata in the master database.)
All metadata are defined using the same collation.
User authentication can be performed by the database, reducing the databases dependency on the logins of the instance of SQL Server.
The SQL Server environment (DMV's, XEvents, etc.) reports and can act upon containment information.
SQL Server 2012 introduced the concept of contained databases. A contained database is a database that includes all of the settings and metadata needed for its operation with dependencies on the instance. From a security perspective, a contained database makes it easier to have user accounts that are limited to a single database. Although contained databases allow more control by the application administrator, they do have security repercussions. The syntax for creating a user for contained database authentication is shown below:
CREATE USER {
windows_principal [ WITH <options_list> [ ,... ] ]
| user_name WITH PASSWORD = 'password' [ , <options_list> [ ,... ] }
[ ; ]
Contained databases are interesting for a security point of view in that they allow defining users with authentication privileges, that is, users who can log directly into a contained database without a corresponding login. Contained databases support two types of users: Windows users and groups that can directly connect to the database and do not need logins, and users with a password where the password is authenticated by the database, not the instance. This is not permitted by default; the instance administrator must specifically allow it by setting the contained database authentication configuration option on. A login trigger can be used to disallow connections to specific contained databases but allow access to other contained databases.
Allowing the direct connection of users to a database changes the effective threat- level of some existing permissions. For example, the permission ALTER ANY USER in a contained database gives permission to add user-based access to an instance through a contained database. Logins with ALTER ANY DATABASE or CONTROL DATABASE permission could also set containment on a database and add instance access through users. In addition, contained database users can connect to other databases in the instance if the guest account is enabled.
Although you can use the system stored procedure sp_migrate_user_to_contained to migrate a database user mapped to a SQL login to a contained database user-with- password, which does not use password history and expiration policies as SQL logins do. However, password complexity checks are still used. Therefore, attaching a contained database could allow weak passwords. In addition, the password hashes for these passwords are stored in the database, not in the master database. Anyone with access to the database file could perform a dictionary attack on a separate, unaudited instance.
There exists the possibility of conflicts, if a login and contained database user have the same name. The rule for resolving this conflict is that if an initial catalog is specified in the connection string and it’s the contained database, access is checking against the user based principal, not the login. To avoid conflicts, do not create conflicting names or specify a contained database as an initial catalog in a connection string. In addition, members of the sysadmin role should not use initial catalog in a connection string.
Best practices for contained databases are as follows:
Use the default (off) setting for contained database authentication and only turn this setting on if it is required.
Protect backups of contained databases using passwords.
Audit the capabilities of users and modules in contained databases.
Audit logins that have the ability to set containment, if contained database authentication is allowed.
Disable the guest account on databases that share an instance with contained databases.
Take care to avoid login/user-with-login naming conflicts.
Avoid connection strings with an initial catalog if contained database authentication is permitted.
Oracle Database 12c pluggable databases
Starting with Oracle 12c, pluggable databases work very similar to contained databases as they can have their own set of users separate from the container database
(Contained user Alice exists)

25. Resources CREATE LOGIN (Transact-SQL) CREATE USER (Transact-SQL)
Contained Databases

26. Lesson 3
Understanding privileges

27. Lesson 3: Understanding privileges
8: Data protection and security
Lesson 3: Understanding privileges
Demo: Viewing privileges
Demo: Granting permissions
Demo: Revoking permissions

28. 40074A
8: Data protection and security
Managing privileges
Oracle and SQL Server control access and activity within the database using system and object privileges
ALTER DATABASE and GRANT are examples of system privileges, while object privileges can be SELECT, INSERT, UPDATE, or DELETE
Oracle and SQL Server use the GRANT statement to give privileges and REVOKE statement to remove privileges; SQL Server can suspend privileges with the DENY statement
 Introduction
Privileges can be assigned to users and roles using the GRANT statement and removed using the REVOKE statement. SQL Server also has the additional DENY statement which prevents users from exercising a privilege even when it has been granted to the user. In SQL Server, the REVOKE statement is used to remove (or cancel out) a previously granted or denied privilege. Conflict in permissions granted directly and through roles is always resolved in favor of the higher-level permission. The only exception to this is if users have been denied permissions (DENY) to an object either explicitly or through their membership in a role. If that is the case, they will not be granted the requested access to the object. It works in the same way as permissions at the Windows operating system level.
The following terminologies relating to privileges in Oracle and SQL Server are equivalent:
Privilege = Permission
System Privilege = Statement Permission
Object Privilege = Object Permission
Predefined Role Permissions = Implied Permissions (for example, DBA vs sysadmin)
GRANTEE = Security Account

29. Demo
Viewing privileges

30. Demo: Viewing privileges
40074A
8: Data protection and security
Demo: Viewing privileges
Using SSMS to view explicit and implicit permissions
Use the system catalog view sys.database_permissions and function fn_builtin_permissions to list permissions on objects and statements in SQL Server

31. Demo
Granting permissions

32. Demo: Granting permissions
USE [AdventureWorks2016] GO
GRANT SELECT ON [HumanResources].[Employee] (BusinessEntityID) TO Demo
GRANT SELECT ON [HumanResources].[Employee] ([Gender]) TO Demo
Provide access to database objects using SSMS
Provide access to objects using T-SQL

33. Demo
Revoke permissions

34. Demo: Revoke permissions
USE AdventureWorks2016 GO
REVOKE SELECT
ON [Person].[Person] ([MiddleName])
TO [User1] AS [dbo]
-- Impersonate User1 and validate that REVOKE does not DENY the User1
EXECUTE AS user='User1'
SELECT * FROM Person.Person;
REVERT
Change the state of permissions
Revoke permissions for users

35. Resources Permissions Hierarchy (Database Engine) GRANT (Transact-SQL)
REVOKE (Transact-SQL)

36. Lesson 4
Managing roles

37. Lesson 4: Managing roles
8: Data protection and security
Lesson 4: Managing roles
Understanding roles
User-defined roles
Demo: Create a database role using SSMS
User-defined server roles
Demonstration: Observe server and database roles

38. 40074A
8: Data protection and security
Understanding roles
Oracle and SQL Server provide system roles with predefined privileges and user-defined roles
Two categories of SQL Server roles:
Fixed and user-defined server roles for the database instance
Fixed and user-defined database roles for a database
Sysadmin fixed server role is equivalent to Oracle DBA role
Oracle: Single DBA role that has database instance wide privileges spanning all schemas
SQL Server: Administrative privileges can be limited by the use of fixed or user-defined database roles
 Resources:
Server-level roles:
Database level roles:

39. Demo
Review server and database roles

40. Demo: Review server and database roles
Server roles
Database roles
Use SSMS to display roles

41. 40074A
8: Data protection and security
User-defined roles
Collects a set of permissions and assigns them a role instead of granting them to individual users
Created using T-SQL or SQL Server Management Studio
Used for groups of users

42. Demo
Create a database using SSMS

43. Demo: Create a database role using SSMS
Create a database role for executing stored procedures
Add a member to the role
Test the permissions for the user

44. User-defined server roles
Server-level principal
Administer defined “server group” contains collection of principals and holds permissions
Compared to fixed roles
Securable class
Permission set can change
Facilitates compliance towards separation of duties

45. Demo
Separation of duties

46. Demo: Separation of duties
40074
2: Database and instances
Demo: Separation of duties
CREATE LOGIN Mary WITH PASSWORD = GO
CREATE SERVER ROLE MyLimitedAdmin AUTHORIZATION sysadmin
ALTER SERVER ROLE MyLimitedAdmin ADD MEMBER Mary
USE master
GRANT CONTROL SERVER to MyLimitedAdmin
DENY SELECT ALL USER SECURABLES to MyLimitedAdmin
Create a sensitive database with data
Create limited sysadmin role
Test the new role
See demo from 40074A_03 HOL Database architecture.docx

47. Working with roles Granting and revoking roles Maintaining roles
8: Data protection and security
Working with roles
Granting and revoking roles
Maintaining roles
Controlling availability of roles
Demo: Observe server and database roles

48. Granting and revoking roles
Role Type
Operation
Oracle
SQL Server
System
Grant
GRANT ROLE role_name TO {user_name | role_name1}
sp_addsrvrolemember
] 'login',
= ] 'role'
Database
N/A
sp_addrolemember
= ] 'role',
= ]
‘security_account'
User
Revoke
REVOKE ROLE role_name FROM {user_name | role_name1}
sp_dropsrvrolemember
] 'role'
sp_droprolemember
] 'role', ]
'security_account'

49. Maintaining roles Operation Oracle SQL Server Drop DROP ROLE role_name
sp_droprole ‘role_name’
Change authentication
ALTER ROLE role_name IDENTIFIED
{BY new_password | USING package_name | EXTERNALLY | GLOBALLY }
ALTER ROLE role_name
WITH NAME = new_name
ALTER SERVER ROLE server_role_name {
[ ADD MEMBER server_principal ]
| [ DROP MEMBER server_principal ]
| [ WITH NAME = new_server_role_name ]
} [ ; ]
The following table covers all the maintenance operations that can be performed in the two relational database management systems and their corresponding syntax.

50. Controlling availability of roles
sp_changegroup ] 'role'
, ] 'user'
In SQL Server, when a role is created, users can be added to the role
You can change the user’s membership to a role different from the current one without dropping and re-creating the user
Controlling availability of roles
In Oracle, roles granted to users have to be enabled before they can be used. Only those roles that have been associated with a username as the default roles are available when the user connects to the database. The generic syntax for this is:
ALTER USER user_name
DEFAULT ROLE {ALL | role_names |
By default, all granted roles are enabled. Granted roles can be enabled or disabled at the session level using the SET ROLE statement.
SQL Server does not have a concept of role enablement except for application roles. When a role is created, it is available and when a user is added to a role, permissions that result from this role are verified when an object access request is made by that user. As in Oracle, a user can be a member of more than one role. Permissions are additive and a user will receive the highest level of permissions through the roles that have been assigned to them. An important distinction worth revisiting here is the DENY statement. DENY will always take precedence over all other GRANT statements regardless.
For example, USER_JOHN may have been GRANTed read access on TableFoo and inherited read access via the READERS_ROLE_01 but USER_JOHN is also assigned the LEGAL_DEPT role which has a DENY read access. This DENY in USER_JOHN’s permissions hierarchy will take precedence over all others so USER_JOHN will not be able to read data from TableFoo. With application roles, an application has to first enable the role by using sp_setapprole (which requires a password for the role) and then can inherit the permissions for that role.
In SQL Server however, you can change the user’s membership to a role different from the current one without dropping and re-creating the user, with the following:
sp_changegroup ] 'role'
, ] 'user'

51. Demo
Observe server and database roles

52. Demo: Observe server and database roles
8: Data protection and security
Demo: Observe server and database roles
Select SP.*
From sys.server_principals AS SP
Inner Join sys.server_role_members As SRM on SP.principal_id = SRM.member_principal_id
Where SRM.member_principal_ID = 1;
Select DP.*
From sys.database_principals DP
Inner Join sys.database_role_members DRM On DP.principal_id = DRM.role_principal_id
Where DRM.member_principal_ID = 1;
In this demonstration, you will learn to:
Use catalog views.
Use stored procedures to analyze roles.
Objectives
After completing this lab, you will be able to view information on permissions and roles granted to users and other roles.
Description
It is easy to manage the permissions in a database if you define a set of roles based on job functions and assign each role the permissions that apply to that job.
Prerequisites
Windows Server 2012 R2 running in Hyper-V
SQL Server 2014 Developer Edition RDBMS installed with the named instance INST01 and sample databases
  Execute two catalog views for principal at the server and database level
Go to Start → Programs → Microsoft SQL Server 2014 → SQL Server Management Studio → Object Explorer.
Select Object explorer → Security.
Click Logins and select the SA login.
Right-click and select Properties to open the Login Properties window.
Select the Server Roles pane in the SQL Server Login Properties window to view the fixed server roles. The user is a member of the roles checked.
Alternatively, use system catalog views to see this information. Open a new Query Editor window and execute the following statement.
Select SP.*
From sys.server_principals AS SP
Inner Join sys.server_role_members As SRM on SP.principal_id = SRM.member_principal_id
Where SRM.member_principal_ID = 1;
Return to the sa Login Properties window. To view the database roles, select User Mapping from the top navigation bar. The window will have information about different roles assigned to the user for different databases.
Alternatively, use the system catalog views to see this information. Open the Query Editor and execute the statement below to see the database users in the db_owner role in the current database.
Select DP.*
From sys.database_principals DP
Inner Join sys.database_role_members DRM On DP.principal_id = DRM.role_principal_id
Where DRM.member_principal_ID = 1;
To view the permissions for a user of specific database, such as AdventureWorks2012, start Object Explorer → Database Instance → Database → AdventureWorks2012. Then, right- click the database and click Properties.
Select Permissions on the Database Role Properties dialog box and click the Add tab to add users or roles to grant or revoke permissions.
To view Table properties <Database Instance> → Database → AdventureWorks2012 → Tables, expand tables, right-click any table, and then click properties.
To view permissions at the columns level of a particular table, select the table and click Columns Permissions.
View permissions on fixed server roles through the SQL Server Login Properties windows. After selecting the server roles in the Server Roles tab, click Server Role. The permission can be viewed by selecting the Permissions tab of this window.
  Use system stored procedures to analyze roles and permissions
To view the list of server roles and get the specific permissions for each role, execute the following procedures:
EXEC sp_helpsrvrole; GO
EXEC sp_srvrolepermission;
To view the list of database roles and get the specific permissions for each role, execute the following procedure:
EXEC sp_helpdbfixedrole;
EXEC sp_dbfixedrolepermission;
(More notes on the next slide)

53. Resources Server-Level Roles Database-Level Roles
Separation of Duties in SQL Server 2014 white paper

54. Module Review Securing the database Managing users
9/10/2018 9:18 AM
Module Review
Securing the database
Managing users
Understanding Privileges
Managing roles
The SQL Server Migration Assistant (SSMA), Microsoft Assessment and Planning Toolkit (MAP) tool, and SQL Server Integration Services (SSIS) combined with Oracle client drivers (and others) can be used in support of the following aspects of an Oracle or SAP migration:
Migration process & tooling
Data deployment
Cloud migration
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.

55. 9/10/2018 9:18 AM
© 2015 Microsoft Corporation. All rights reserved. Microsoft, SQL Server, Windows, 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.
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, 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.