module 5 designing security for sql server 2008
Post on 22-Feb-2016
55 Views
Preview:
DESCRIPTION
TRANSCRIPT
Module 5
Designing Security for SQL Server 2008
Module Overview
• Exploring Security in SQL Server 2008
• Implementing Identity and Access Control
• Guidelines for Secure Development in SQL Server 2008
• Guidelines for Secure Deployment of SQL Server 2008
• Guidelines for Secure Operations
Lesson 1: Exploring Security in SQL Server 2008
• Overview of Securing SQL Server 2008
• SQL Server 2008 Security Changes
• SQL Injection Attacks
• SQL Server 2008 Regulatory Compliance
• Discussion: Preventing SQL Injection Attacks
Platform and Network Security
Principals and Database
Object SecurityApplication Security
• Limit physical access to the server, hardware components and backup media • Apply all updates and upgrades to the operating system after you test them
with the database applications • Restrict access to operating system files
• Reduce the SQL Server surface area by configuring set of permission of securable
• Enhance object and connection security by creating certificates
• Write secure client applications
Overview of Securing SQL Server 2008
Platform and Network Security
Principals and Database
Object SecurityApplication Security
SQL Server 2008 Security Changes
Windows Local Group Changes
Surface Control Tools Changes
Kerberos Authenticationü
ü
ü
Major security changes in SQL Server 2008 are:
SQL Injection AttacksTo reduce the scope for injection attacks:
Accept only expected values of string variablesü
Avoid assumptions about the data size, type, or contentü
Test the size and data type of inputü
Use stored procedures to validate user inputü
Validate XML data with the related XML schemaü
Avoid building T-SQL statements directly from user inputü
Validate all data in multitiered environmentsü
Implement multiple layers of validationü
Avoid concatenating unvalidated user inputü
Avoid accepting strings such as AUX and CLOCK$ü
Var ShipCity;ShipCity = Request.form ("ShipCity");var sql = SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'
SQL Server 2008 Regulatory Compliance
•Sarbanes-Oxley Act (SOX)•Gramm-Leach-Bliley Act (GLBA)•Health Insurance Portability and Accountability Act (HIPAA)•FDA Title 21 CFR Part 11•California Senate Bill 1386•Common Criteria
You must adhere to the following acts, regulations, and certifications to implement effective security mechanisms:
Discussion: Preventing SQL Injection Attacks
• Describe SQL injection attack.
• What measures can you take to minimize the risk of SQL injection attacks?
• Can you completely prevent SQL injection attacks?
• Considerations for Using Principals
• Considerations for Using Roles
• Considerations for Using Securables
• Considerations for Using Permissions
• Discussion: Using a Loginless User Account
Lesson 2: Implementing Identity and Access Control
Considerations for Using Principals
• Every database includes INFORMATION_SCHEMA and sys entities
• Server principals with names within double hash (##) marks are only for internal use
• Every database user belongs to the public database role
• The guest user account cannot be dropped, but can be disabled by revoking its CONNECT permission
• The SQL Server sa login is a server-level principal
• Application roles help control user access to specific data
Considerations for Using Roles
Every database user belongs to the public database role ü
Members of the db_ssisadmin role and the dc_admin role may be able to elevate their privileges to sysadminü
By default, the BUILTIN\Administrator group is not included in the SQL Server 2008 sysadmin fixed server roleü
The Windows groups created for use by the SQL Server service are not included in the sysadmin fixed server roleü
Flexible database roles are not added as members of fixed rolesü
Considerations for Using Securables
Securables are the resources to which the SQL Server Database Engine authorization system regulates access.
Ownership chaining enables managing access to multiple objects by setting permissions on one object.
Ownership Chains
File access permissions are set during operations, such as creating, attaching, modifying to add a new file, backing up, or restoring databases.
Data Security
Schemas hold objects, such as tables and views.
Every securable in a specific schema must have a unique name.
Schema
Considerations for Using Permissions
Permissions for Fixed Database Roles
Permissions for Fixed Server Roles
Catalog Views
sys.server_permissions
sys.database_permissions
Principals and SecurablesWindows Level
Server Level
Database Level
Discussion: Using a Loginless User Account
• Describe a loginless user account.
• What are the benefits of having a loginless user?
Lesson 3: Guidelines for Secure Development in SQL Server 2008
• Guidelines for Execution Context
• Using Module Signing
• Guidelines for Context Switching
• Demonstration: How To Control Execution Context by Using the EXECUTE AS Clause
• Guidelines for Impersonation
Guidelines for Execution Context
• Valid only for a specific database• Contains the primary and secondary
identities against which database-level permissions are checked
User Security Token
Execution context is represented by security tokens. A security token contains:• One server or database principal as the primary identity• One or more principals as secondary identities • Zero or more authenticators• Privileges and permissions of the primary and secondary identities
• Valid across the instance of SQL Server
• Contains the primary and secondary identities against which server-level permissions and database-level permissions are checked
Login Security Token
Verifying data
Using Module Signing
</1010>
Signer Private key
</1010></1010>
Verifier Public key
Signing data
</1010>
Guidelines for Context Switching
Explicit Server-Level
Explicit Database-Level Implicit
• The EXECUTE AS LOGIN = 'login_name' statement is used to switch execution context at the server level
• The login name must be visible as a principal in sys.server_principals• The statement caller must have IMPERSONATE permission on the
specified login name
• The EXECUTE AS USER = 'user_name' statement is used to switch execution context at the databse level
• The user name must exist as a principal in sys.database_principals• The caller must have IMPERSONATE permissions on the specified user name
• The execution context of a module can be implicitly changed by specifying a user or login name in an EXECUTE AS clause in the module definition
• The user that the module is impersonating needs to have permissions on the objects accessed by the module
Explicit Server-Level
Explicit Database-Level Implicit
Demonstration: How To Control Execution Context by Using the EXECUTE AS Clause
In this demonstration, you will see how to:
Use EXECUTE AS to switch execution context
• Server or database principals other than sa or dbo can call EXECUTE AS• The scope of impersonation is explicitly defined in the EXECUTE AS statement• With EXECUTE AS, the impersonation remains in effect until the session is dropped• You can create an execution context stack by calling the EXECUTE AS statement
multiple times across multiple principals
Windows User
SQL Server Instance
SQL Service Provider
Guidelines for Impersonation
SQL Server Impersonation Within a Domain
Advantages of the EXECUTE AS statement vs. SETUSER statement
Lesson 4: Guidelines for Secure Deployment of SQL Server 2008
• Guidelines for Using Authentication Modes
• Features of SQL Server Configuration Manager
• Discussion: Using Policy-Based Management
• Windows authentication is the default authentication mode
• Windows Authentication mode enables Windows authentication and disables SQL Server authentication
• SQL Server validates user credentials by using a Windows principal token
• A connection made by using Windows authentication is called a trusted connection
• Kerberos security protocol in Windows authenticationenforces password policy
• Mixed mode authentication enables both Windows authentication and SQL Server authentication
• It requires a strong password for the built-in SQL Server system administrator account named sa. The sa account connects by using SQL Server authentication
Guidelines for Using Authentication Modes
During setup, you must select an authentication mode for the Database Engine
Mixed Mode Authentication Windows Authentication Mode
Features of SQL Server Configuration Manager Protocols, Connection, and Startup Options:
• Use the SQL Server Services area to start components and configure theautomatic starting options
• Use the SQL Server Network Configuration area to enable connection protocols andconnection options
Command-prompt Options:
• Use the Invoke-PolicyEvaluation SQL Server PowerShell cmdlet to invoke Surface Area Configuration Policies
SOAP and Service Broker Endpoints:• Use Policy-based Management to turn endpoints off• Use CREATE ENDPOINT and ALTER ENDPOINT to create and alter the properties of
endpoints
Enabling and Disabling Features:
• Use facets in SQL Server Management Studio to configure enabling and disabling features• Use Policy-based Management to check the configuration of a facet
Discussion: Using Policy-Based Management
Discuss how policy-based management can be used to regularly inspect and verify that the specific security requirements are actively in place.
Lesson 5: Guidelines for Secure Operations
• Guidelines for Creating a Password Policy
• SQL Server Cryptography Architecture
• Using SQL Certificates and Asymmetric Keys
• Guidelines for Using SQL Server Encryption
• Cell-Level Encryption
• Demonstration: How To Enable TDE
• Discussion: Securing Data by Using Encryption
Guidelines for Creating a Password Policy
Password expiration
Use password expiration to manage the lifespan of a password
Policy enforcement
Configure password policy enforcement separately for each SQL Server login
Password complexity
Use password complexity to prevent brute force attacks
SQL Server Cryptography Architecture
Service Master Key
Database Master Key
Symmetric Key
Asymmetric KeyCertificate
Using SQL Certificates and Asymmetric Keys
Use certificates and asymmetric keys for asymmetric encryption
• You can use certificates as containers for asymmetric keys and to sign code modules
• You can use externally generated certificates or certificates generated by SQL Server
• You can specify properties for the certificates while creating them
• Asymmetric keys are used for securing symmetric keys, limited data encryption, and digitally signing database objects
• Asymmetric keys can be imported from strong name key files, but they cannot be exported
• Asymmetric keys do not have expiry options
• Asymmetric keys cannot encrypt connections
Asymmetric Keys
SQL Certificates
Demonstration: How To Enable TDE
In this demonstration, you will see how to:
Enable TDE by using the ALTER DATABASE statement
Discussion: Securing Data by Using Encryption
• How do you decide about what data to be secured by encryption?
• Why would you secure an entire database by encryption?
• What is data at rest?
Lab 5: Designing Security for SQL Server 2008
• Exercise 1: Designing Secure Development
• Exercise 2: Implementing Secure Operations
• Exercise 3: Enabling Database Encryption
Estimated time: 60 minutes
Logon Information
Virtual machine
User name
Password
NYC-SQL1
Administrator
Pa$$w0rd
Lab Scenario
You are a lead database designer at QuantamCorp. You are working on the Human Resources Vacation and Sick Leave Enhancement (HR VASE) project that is designed to enhance the current HR system of your organization. This system is based on the QuantamCorp sample database in SQL Server 2008.
The main goals of the HR VASE project are as follows:
• Provide managers with current and historical information about employee vacation and sick leave.
• Grant view rights to individual employees to view their vacation and sick leave balances.
• Provide permission to selected employees in the HR department to view and update the vacation and sick leave details of employees.
• Grant the HR manager with the view and update rights to all the data.
• Ensure that the application compiles with local regulations by verifying that the sensitive information is protected and unauthorized access to the application is prohibited.
You are required to design a security access control policy and examine the various aspects of secure development and operation in the SQL Server database system.
Lab Review
• How can schema help to improve management of database security?
• Does configuration of TDE for a database ensure encryption of the associated FILESTREAM data?
• How do you restore an encrypted database if the certificate that protects the database encryption key is unavailable?
• How will you configure the client application to utilize TDE?
Module Review and Takeaways
• Review Questions
• Real-World Issues and Scenarios
top related