* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Module 2: Authoring Basic Reports
Survey
Document related concepts
Entity–attribute–value model wikipedia , lookup
Oracle Database wikipedia , lookup
Concurrency control wikipedia , lookup
Microsoft Access wikipedia , lookup
Ingres (database) wikipedia , lookup
Team Foundation Server wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Clusterpoint wikipedia , lookup
Versant Object Database wikipedia , lookup
Database model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Transcript
SQL Server 2005 Security Enhancements Dr Greg Low Senior Consultant Readify [email protected] Original version of this material was DAT330 TechEd 2004 presented by Girish Chander Agenda Yukon Security Features Authentication Endpoint Based Authentication Password Policy Enforcement Strengthening SQL Authentication Authorization User-Schema Separation Module Execution Context Granular Permissions Control Catalog Security Crypto support Data Encryption Endpoint-Based Authentication Endpoint: Point of entry into an instance Binds transport protocol to payload Transport Protocol Named pipes Shared Memory TCP HTTP VIA Payloads TDS SOAP SSB Database Mirroring For HTTP Off by default, Endpoints need to be explicitly created No permissions on endpoint by default Endpoint-Based Authentication (Cont) For Other transports Default endpoint created for every enabled transport at start up CONNECT permissions granted to authenticated logins Permissions can be denied on a per endpoint basis Advantages Transport/payload based access management Controlled within SQL Server Ability to start/stop/disable individual endpoints SQL Server Security Model Network connection request Connect to the SQL Server computer Login authentication request to SQL Server Establish login credentials; Authorize against EP Switch to a database and authorize access Establish a database context Attempt to perform some action Verify permissions for all actions Password Policy Enforcement Enforcement of the following on logins Password strength Password expiration Account lockouts Follows local Windows password policy Supports consistent enterprise wide policy Approach New password policy check API in Windows Server 2003 Called during Authentication, password set and reset On Win2K server API not available Only supports SQL server native password complexity Password Policy For Logins Secure by default Policy checked for all logins by default Can be configured on a per login basis Admin options on logins Turn ON/OFF Password policy checks Turn ON/OFF Password expiration checks Requires Password Policy to be ON Gives ‘password never expires’ ability Ability to force password change on first login Present in the sys.sql_logins catalog view *** Password Policy For Logins During Authentication Account lockout in case of brute force attack Password age restrictions – if expiration set Password Set/Change Password complexity enforced and history checked Client side support Allows password change on login, similar to Windows Ability to disable logins quickly Password Policy Enforcements Strengthening SQL Authentication Stronger channel for authentication protocol for standard SQL logins Channel is encrypted using SQL generated certificates No SSL certificate loading required Similar to current SSL implementation Default mechanism for standard SQL logins for Yukon clients talking to Yukon server Seamless to applications; No application change required Support for old style authentication for down level clients Agenda Yukon Security Features Authentication Endpoint Based Authentication Password Policy Enforcement Strengthening SQL Authentication Authorization User-Schema Separation Module Execution Context Granular Permissions Control Catalog Security Crypto support Data Encryption User-Schema Separation Separation of principals and schemas Principal Entities against whom objects are secured Live in the sys.database_principals view Schema Container of objects; 3rd part of 4 part name Live in the sys.schemas view User-Schema Separation (Cont) Notion of default schema Property of User or Application role Used in name resolution; Look up algorithm for objects Maintained in sys.database_principals New DDL for user and schemas CREATE/ALTER/DROP for USER, ROLE, and SCHEMA Dropping user does not require application re-write User-Schema Separation The Solution User 2 Table Function View Stored Proc contained in Schema User-Schema Separation The Solution User1 User2 Default Schema S1 User3 Select * from foo •S1. foo •Dbo.foo Default Schema Used for name resolution purposes Not all users need to own schemas Gives the ability to share out name resolution look up across many users DBO schema need not be the only shared schema, from name lookup perspective Default Schema (Cont) Why is this useful? To create objects guaranteed to hit name lookups from every context, objects need not be created in DBO schema By having these contexts point to another schema as the default schema Allowing creation of objects in DBO schema could pose security risks through ownership chaining This can be mitigated using ‘lower privileged’ schemas as the default schema ‘lower privileged’: Owned by a lower privileged account User-Schema Separation Database can contain multiple schemas Each schema has an owning principal – user or role Each user has a default schema for name resolution Most database objects live in schemas Object creation inside schema requires CREATE permission and ALTER or CONTROL permission on the schema Example: Creation of table in schema requires CREATE TABLE permission and ownership of schema or ALTER or CONTROL on schema Ownership chaining still based on owners not schemas Database Has default schema Owns Schema1 Approle1 User1 Role1 Owns Schema2 Schema3 SP1 Fn1 Tab1 Owns User-Schema Separation Execution Context SQL 2000 Execute Perms checked for User3 Select Perms checked for User3 User2.Proc1 User1.T1 User1.Proc1 User1.T1 Execute Perms checked for User3 NO Perms checked for User3 User 3 Yukon ‘Execute AS ‘X’ ’ User 3 User2.Proc1 Execute Perms checked for User3 User1.T1 Select Perms checked for ‘X’. Not for user3 Module Execution Context Ability to choose execution context of modules Module: Stored procs, functions, triggers No need to rely on ownership chaining to get ‘upfront permission check’ behavior Ownership chaining rules still apply however Module Execution Context (Cont) Permissions checked against current execution context Unlike Ownership chaining, applies to DDL as well Option available for dynamic SQL as well Alternative to the absence of ownership chaining Execution context maintained in the sys.sql_modules catalog view Contexts Execute AS CALLER Statements execute as immediate calling context Default behavior, Similar to SQL Server 2000 Use when caller’s permission needs to be checked, Or ownership chaining will suffice Execute AS ‘UserName’ Statements execute as the username specified Impersonate permission required on user specified Contexts Execute AS SELF Statements execute as the person specifying the execute as clause for the module May be useful in application scenarios where calling context may change Execute AS OWNER Statements execute as the current owner of the module Impersonate privileges on owner required, at setting time On ownership change, context is new owner Using Execute As To Create Permission Buckets Scenario Database Admin wants to delegate the ability to truncate a set of tables each night Problem Truncate is not a grantable permission Closest covering permission is ALTER, but that is too high and gives other ability Using Execute As To Create Permission Buckets (Solution) Solution: Execute As to the rescue Create a Proc that truncates the table Mark it to execute as a user with ALTER permissions Grant execute permission to the target user Result You’ve just made Truncate a grantable permission! Module Execution Context Granular Permissions Control More permissions – at multiple scopes Server, Database, Schema, Object, Principal Principle of least privileges Assign only required permissions to perform an action Granular permissions enable that Many new permission verbs added for granular control SQL 2000 fixed roles still supported Catalog Views Database permissions live in sys.database_permissions view Server permissions live in sys.server_permissions view Permission States Three permission states Grant gives a right Deny explicitly denies a right Revoke takes away an existing grant or deny Grant - Revoke Revoke [deny] + DENY Grant Deny General Permissions Scheme Grantee Server level permissions grantable to logins Database level permissions grantable to users/db roles/application roles Securable Entity to be secured Example: Tables, assemblies, databases, server, etc… Same permission can be at multiple scopes Example CONTROL on schema level and CONTROL on table within a schema DENY at any level always take precedence General Permissions Scheme Most securables have the following permissions CONTROL: Owner like permissions ALTER: Ability to change the properties of the securable. Also grants the ability to CREATE/DROP/ALTER sub entities Example: ALTER permission on a schema allows altering the name of the schema; And also altering tables, views etc. within schema General Permissions Scheme (Cont) ALTER ANY ‘X’: Ability to alter any object of type X Example: ALTER ANY ASSEMBLY allows altering any assembly in the database Take Ownership: Grants the ability to take ownership of an object New permissions Further Examples Concern: I want to delegate auditing power without giving access to the entire server Solution: ALTER TRACE New server level permission. Sysadmin no longer required to run profiler Concern: There is db_datareader and db_datawriter, but I want a db_procexecutor equivalent Solution: EXECUTE (higher scope--database or schema) Can execute any proc/function/assembly in database, or schema (if schema scoped) Equivalent SELECT, INSERT, UPDATE, DELETE permissions introduced as well New permissions Further Examples Concern: I want to be able to selectively impersonate another user, without having full database, or instance privileges Solution: IMPERSONATE (for login and user) No longer require sysadmin or DBO for impersonating user/login Catalog Security System tables implemented as views: Catalog views Metadata is secured by default Minimal permissions to public Catalog views are row level secured Need to be owner or have some permission on object to see it in catalog view SA can see everything in server DBO can see everything in database New permission to allow viewing of metadata VIEW DEFINITON Applicable at object level, schema level, database, and server level Agenda Yukon Security Features Authentication Endpoint Based Authentication Password Policy Enforcement Strengthening SQL Authentication Authorization User-Schema Separation Module Execution Context Granular Permissions Control Catalog Security Crypto support Data Encryption Encryption Support Inside DB Encrypt and Decrypt built-ins for encryption support Encryption built-insEncrypts cleartext and returns ciphertext *** EncryptByKey() EncryptByCert() EncryptByPassphrase() Decryption built-insDoes the reverse Symmetric Keys and Certificates Used for encryption/decryption Entities inside SQL Server Support for creation and storage in SQL Symmetric keys and private keys always stored encrypted in SQL Symmetric Keys Entities inside the database CREATE SYMMETRIC KEY DDL Used in the built-ins for encryption and decryption Keys are always stored encrypted or in ‘closed’ state Usage of Key requires ‘opening’ the key OPEN KEY DDL Involves decrypting the key Knowledge of mechanism used to encrypt the key required Once ‘open’, keys can be used until they are ‘closed’ or sessions is terminated All keys are encrypted in memory Catalog views Sys.symmetric_keys Sys.Open_keys Certificates Entities inside the database CREATE CERTIFICATE DDL Can be loaded into SQL Server Private key is optional Required if signing, decryption, or authentication is needed Can be created in SQL Server SQL server generates the certificates Support for ‘dumping’ certificates and private keys Private keys always stored encrypted Required for Service Broker: Authentication and message integrity and secrecy Encryption support Securing SQL authentication natively Module Signing Encryption Layers Database Master Key A Key that is specific to the database Used to secure certificate private keys inside the database Explicitly created by owner of the database Support for regeneration and recovery ALTER MASTER KEY DDL DUMP/LOAD MASTER KEY DDL Always secured using user password Stored in the database Can also be secured using Service Master Key Used when SQL server does key management Does not rely on user password to get to key Stored in the sysdatabases table Service Master Key Key that is specific to the instance Used to secure system data Linked server passwords Connection strings Database Master keys Mapped account credentials Created upon install Support for regeneration and recovery ALTER SERVICE MASTER KEY DDL DUMP/LOAD SERVICE MASTER KEY DDL Secured using DPAPI The service accounts credentials Encrypting Data The SQL Server 2005 University Masters Fully accredited, masters level degree from Charles Sturt University SQL Server 2005 MCDBA certification included as an integral component Graduates eligible for full professional level membership of the Australian Computing Society Part time study delivered via Distance Education Qualifies for Government FEE-HELP program Places available for experienced applicants without previous qualifications First intake commences September 2005 Register your interest at www.itmasters.info Technical Readiness Resources Microsoft SQL Server 2005 Workshops 1 or 2 day hands on workshops on each of : Database Infrastructure Database Development Business Intelligence Tour 1 Starts Mid May Tour 2 has been added due to popular demand – starts late August Event: Microsoft SQL Server 2005 Workshops Microsoft SQL Server 2005 Database Infrastructure & Scalability Presented by Brent Challis from DDLS this workshop covers Installation and upgrade options, Management tools, Architecture, Security enhancements, Scalability and performance enhancements and Maintenance enhancements. Microsoft SQL Server 2005 Development This intensive workshop led by Greg Low from Readify, this workshop covers the developer-related enhancements in SQL Server 2005, with a focus on T-SQL enhancements, CLR Integration, Security enhancements and ADO.NET enhancements. Microsoft SQL Server 2005 Business Intelligence Presented by Peter Myers from Tenix Connections, this workshop covers the building of Analysis Services 2005 databases, cubes, dimensions, & aggregations, enhancements made to MDX, the new Integration Services 2005 (formerly DTS), the new data mining algorithms of Analysis Services 2005 and creating reports from Analysis Services cubes. http://www.microsoft.com/australia/events/sql2005/ Microsoft SQL Server 2005 Workshops - Dates City Sydney Canberra Melbourne Brisbane Perth Adelaide MS SQL Server 2005 Database Infrastructure & Scalability MS SQL Server 2005 Development MS SQL Server 2005 Business Intelligence 23-24 May [ SOLD OUT] 30-31 May [SOLD OUT] 6-7 June 9-10 June 14-15 June 21-22 June 22-23 August 1-2 September 7-8 September 26-27 May 1-2 June 7-8 July 25-26 August 5-6 September 14-15 September 20-21 June 27-28 June 4-5 July 6-7 September 12-13 September 21-22 September 23-24 June 30 June-1 July 9-10 June 19-20 September 26-27 September 6-7 October 4-5 July [SOLD OUT] 6-7 July [SOLD OUT] 11-12 July 26-27 September 4-5 October 12-13 October 20-21 July 18-19 July 14-15 July 4-5 October 10-11 October 17-18 October http://www.microsoft.com/australia/events/sql2005/ Thanks for listening! [email protected] © 2002 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.