0% found this document useful (0 votes)
51 views44 pages

SQL Server 2005 Overview

The document provides an overview of Microsoft SQL Server 2005, highlighting new features in manageability, availability, scalability, developer productivity, and security. It emphasizes the importance of security measures, including a layered defense strategy, user-schema separation, and SQL injection mitigation techniques. Additionally, it discusses encryption practices and best practices for securing SQL Server environments.

Uploaded by

prashant j
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
51 views44 pages

SQL Server 2005 Overview

The document provides an overview of Microsoft SQL Server 2005, highlighting new features in manageability, availability, scalability, developer productivity, and security. It emphasizes the importance of security measures, including a layered defense strategy, user-schema separation, and SQL injection mitigation techniques. Additionally, it discusses encryption practices and best practices for securing SQL Server environments.

Uploaded by

prashant j
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd

SQL Server 2005 Overview

Rafal Lukawiecki
Strategic Consultant
Project Botticelli Ltd
[email protected]

This session is based on the results of my close co-operation with my great friend Kimberly Tripp, as well as
an article of Michelle Dumler on SQL Server new features. See summary for references.
2

Objectives

Introduce a selection of new features in


Microsoft SQL Server 2005
Concentrate on how SQL Server 2005 Security
3

Overview of New
Features
4

Introducing New Features

Over 5 years of work means many new and


interesting features. Let’s group them:
Manageability
Availability
Scalability
Developer Productivity
Security
5

Manageability

Management Studio
One place for all SQL Server tasks
Performance Monitoring and Tuning
Less “black magic” needed, good self-tuning, but
>70 new internal measures exposed for your use
SQL Management Objects (SMOs)
Programmatic administration of SQL through a new
set of .NET objects
6

Availability

Failover clustering and mirroring


Complementary solutions; mirroring likely to ship a
little after SQL 2005 does
Database snapshots
Instant, read-only views that self-update
Fast recovery
While roll-backs are still completing
Dedicated admin connection
Even if regular access no longer possible
7

Scalability

Snapshot Isolation
Transactionally consistent view up to last committed
record for analysis (e.g. OLTP) purposes
Replication Monitor
Toolkit for automating complex replication
Table and Index Partitioning
Horizontal partitioning, especially for terabyte
databases
64-bit Optimisation
8

Developer Productivity: .NET

CLR/.NET Framework support


New languages available, with C# and VB the main
likely development environments
Can do things that were either extremely complex in
T-SQL (e.g. RegEx), or quite unsafe (e.g. requiring
extended stored procedures)
Strong-typing with user-defined data structures
Common development and debug environment
Performance!
Yes, .NET precompilation is pretty good
9

Other Developer Goodies

T-SQL Updates:
Recursive
queries, error
handling, new
feature support
Business Intelligence
Development Studio
Based on Visual
Studio,
encompasses
tasks for
managing the
database engine,
reporting and
analysis services
10

Data Access and Web Services

ADO.NET 2.0 – Revamped, with support for


notifications, multiple active result-sets (MARS)…
Query Notifications
Notifications are sent from SQL if data that underlies results
from a query changes
Supported in ADO.NET, OLEDB, ODBC, ADO and SOAP
Useful for remote cache updates for web apps

Service Broker
SQL’s nod to Service Oriented Architectures (SOA), through
asynchronous message routing as an application framework
11

Security of SQL
Server 2005
12

Whose Fault was SQL Injection?

OK. I have your attention. It was not you


anyway, of course.
Security for a database developer was a very
rude wake-up call.
I feel your pain.
I can help you – in this session.
13

Defense in Depth
Using a layered approach:
Increases an attacker’s risk of detection
Reduces an attacker’s probability of success

Data Permissions, encryption

Application Application hardening, authorization

Host OS hardening, SQL Server patching

Internal Network SSL, IPSec, No problems

Perimeter Firewalls, packet filters

Physical Security Guards, locks, tracking devices,


HSM, tamper-evident labels
Policies, Procedures, &
Awareness DBA education against social
engineering
14

Authorization Model

How things used to work?


User-schema separation
Granular permissions
EXECUTE AS
SQL Injection (Classic)
SQL Injection (Future)
15

Security through Encapsulation

Granting access to a process or a method


without direct access to base objects
How?
Grant access to the stored procedures, views
and/or functions without granting access to the base
object
Requires
The objects in the dependency chain cannot be
broken (object ownership chaining)
The user has to have direct base object access
(which is what you’re trying to avoid)
16

Do NOT Give Base Object Access


The SQL Server 2000 Way

dbo.Sales
dbo.Sales dbo.DeleteASales
dbo.DeleteASales

has NO direct permissions Granted execute access


may even be DENIED permissions to Sales to procedure

Only works when the object


dependency chain is NOT
User
broken
User
Only works when the
commands inside of the
stored procedure are not
built/executed dynamically
17

User-Schema Separation
Database can contain Database
multiple schemas
Each schema has an owning
principal – user or role User1 Approle1
Role1
Has
Each user has a default schema default
for name resolution Owns schema Owns

Database objects live Schema1


Owns
Schema2
in schemas
Object creation inside schema
requires CREATE permission Schema3
and ALTER or CONTROL SP1
permission Fn1
on the schema Tab1

Ownership chaining still based


on owners not schemas
18

Do NOT Give Base Object Access


The SQL Server 2005 Way

Create a schema – for example one which


contains procedures (and possibly even base
tables) and then GRANT EXECUTE at the
schema level
Add objects to appropriate schema
Grant access to the schema or the individual
objects – if chaining is required, it is still based
on the owner… the owner of the schema
19

What if Dynamic String Execution

By default – and for better security – if the stored


procedure has a statement which is built
dynamically (using EXEC('string') or
EXEC(@variable)) then the context under which
the dynamically constructed string executes is
ALWAYS the caller
Which is what helps to prevent some forms of
SQL Injection
This is really a good thing BUT…
Can be limiting
Enter: EXECUTE AS
20

Module Execution Context


Execute AS CALLER
Default behavior, same as SQL Server 2000
Use when caller’s permission needs to be checked – or when ownership
chaining will suffice
Execute AS 'UserName'
Statements execute as the username specified
Impersonate permission required on user specified
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
Execute AS SELF
Statements execute as the person specifying the execute as clause for the
module – even if the ownership changes
May be useful in application scenarios where calling context may change
21

EXECUTE AS…

Solves problems
Allows permissions to be granted where never
possible (e.g. granting truncate table)
Wrap ANYTHING inside a stored procedure and set
the context to run as someone who has permissions
– even dynamic string execution – then give
execute permission
Creates potential for further SQL Injection
What if you’re code is not well tested and uses
dynamically executed strings
22

SQL Injection

SQL statement(s) or clause(s) injected into an


existing SQL command
Injected string appended to application input
Text boxes
Query strings
Manipulated values in HTML
Why SQL injection works?
Application accepts arbitrary user input
Connection made in context of higher privileged
account
23

SQL Injection Mitigation

Do not trust the user’s input!


Look for valid input and reject everything else
Regular expressions (regex) are your friend!
Do not use string concatenation
Use parameterized queries to build queries
Restrict information in error messages
Use a low-privileged account
DO NOT use sa or sysadmin role member
24

Code Signing

A module can be signed with a certificate


Separately, e.g. in another database, you can map
signatures made by a specific certificate to a user
Authorizing that mapped user allows you to provide
cross-database permissions without the use of
EXECUTE AS

Trust is established between databases by exporting and


importing the certificate
This application is likely to be of more use in the future, as
today it is not possible to export signed code outside of a
database
Esoteric applications exist, though: sophisticated trust control
within a deep structure of ownership of database objects
25

Data Protection

Use of cryptography to protect the data layer from theft


or manipulation
Particularly important if offline data is in transit
Important for regulatory reasons
Prevent admin from access
SarbOx

Manipulation (integrity) protection uses digital signatures


Not implemented for data in SQL Server 2005
Can overcome this with judicious use of encryption alone
Implemented for code signing
26

Check Your OS
XP SP2 WS2003

Verify what algorithms DES 56 (64) 56 (64)


and key lengths are 3DES 128 128
supported by your OS, as
this depends on your AES128 - 128
CSP (Cryptographic AES192 - 192
Services Provider)
AES256 - 256
Generate keys for all
algorithms then look in RC2 128 128
the sys.symmetric_keys
RC4 40 40
At present, there is no
way to change the CSP… RSA 2048 2048
27

Before You Begin

Your DBA must ensure that the server has a Service


Master Key (SMK) that agrees with your disaster
recovery strategy and a Database Master Key (DMK)
has been created for each database that will use
encryption
See later for more detail
ALTER SERVICE MASTER KEY can be used to change
recovery options
CREATE MASTER KEY ENCRYPTION BY PASSWORD =
Use a strong password, write it down and keep it safe
28

Key Generation

The key should be impossible to guess.


Preferably random.
CREATE xSYMMETRIC… will generate a fairly
random key for you – good!
You can base the key on data supplied by you, use
KEY_SOURCE clause – good for generating
identical keys from a high-quality password
29

Passwords
Make sure passwords used to protect or create keys are
very strong
In our opinion, it is better to create a very long and
complex password that you will have to write down and
store in a well-protected safe in your company
You can divide it into two halves and store in separate
envelopes in different safes
E.g.: *87(HyfdlkRM?_764#{(**%GRtj*(NS£”_+^$(
No dictionary words, more than 20 characters, many non-
printing characters
Challenge: usability!
Consider also:
Not keeping passwords as text in your code, but store and
retrieve them through DPAPI and a .NET component
Using good quality password generators
30

Key Protection
SQL Server 2005 insists that the key you create is
further encrypted for its protection
Yes, that’s double-encryption, but that is not double-security.
Actually, it reduces security a little in some cases
CREATE SYMMETRIC…ENCRYPT BY
PASSWORD
Your (v. good) password generates a key to 3DES encrypt the
key you are protecting
Note, 3DES is less secure than AES, so this
CERTIFICATE
Your key is encrypted using the public key of a certificate
This, in essence, is hybrid encryption
If private key is kept secure (and offline), this is a very good way
to protect a symmetric key
Or another SYMMETRIC or ASYMMETRIC key – less useful
but interesting
31

Encryption

1. Create or retrieve the key


2. Open the key – this means decrypt it with its
(secondary) password or certificate or other
key
3. Use function ENCRYPTBYKEY inside DML
32

Decryption

1. Create or retrieve the key


2. Open the key
3. Use function DECRYPTBYKEY inside SELECT
and all other DML
33

Key Protection Hierarchy in SQL


Key
Secured By

User Password Certificate Another key


Associated with… Wraps the …

Private Key Public Key


Secured By

Password Master Key


Secured By

Service Key
Secured By DPAPI
34

Managing Service Master Key (SMK)

SMK used to separate the relationship between


DPAPI and machine dependency
DPAPI supports password changes but not
Service Account changes
With SMK abstraction, account can be changed
and encrypted data does not need to change
However, what happens when a database
needs to be used on alternate server?
35

Managing Service Master Key


Single Server v. Multiple Servers

SMK is machine dependant


Can “dump” certificate to use on secondary/mirror
servers to keep SMK in sync
If not in sync, encrypted data will be unavailable
until database master key is re-encrypted with SMK
of destination server
Special considerations for mirror and automation of
re-encryption through certificate store
36

SQL Server 2005 – Secure by Default

SSL certificate created if doesn’t exist


Login Policies
Server Side
Check_Policy---Default ON
Check_Expiration---Default OFF
Client Side Support
Password Change at login
37

Protecting SQL Credentials

Requires a secure channel


IPSEC, SSL
In previous releases required admin to setup
SSL/IPSEC certificate
Not secure by default
In SQL SERVER 2005
SSL certificate automatically generated
Prevents passive man-in-the-middle attacks
38

Encryption Over the Wire

Login Credentials Encryption


Uses SSL certificate from certificate store (if
available)
Can be explicitly chosen using Certificate Picker in
SQL Server Configuration Manager
Otherwise, will use SQL generated Certificate
(master.sys.certificates)
Data packets can be encrypted
Server Side Option: ‘Force Protocol Encryption’
Client Side: Encryption with or without certificate
validation
39

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
40

New Permission Examples

CONTROL
Ownership-like permissions
ALTER
Ability to alter properties – and/or hierarchy
On higher scopes, confers ability to add, drop and
alter sub scopes
ALTER ANY ‘X’
Example: ALTER ANY ASSEMBLY

TAKE OWNERSHIP
Ability to take ownership of object
41

Auditing

Successful and failed logins


sp_configure ‘c2 auditing’ (superseded by FIPS-
140-2 Common Criteria but still supported)
Profiler Security Event Class
Events: Add Database User, Addlogin, DBCC
events, Change Password, GDR events
(Grant/Deny/Revoke events), Server Principal
Impersonation event
Data Column: SessionLoginName
42

Top 10 Best Practices


1. Risk assessment and threat analysis
2. Trap “developer quality” error messages – avoid
indecent disclosure
3. Avoid using dynamic string execution
4. Think encryption for sensitive data
5. Do not create objects in DBO schema
6. Hide underlying application schema
7. Use Roles for managing permissions
8. Account for catalog security
9. Avoid encryption as it precludes indexing and
performance
10. Know your CSP. Check allowed key lengths if
needed. Chose carefully!
43

Summary

Microsoft SQL Server 2005 makes proactive application-


level security finally possible
It has been designed for scalability, availability and
manageability needs of modern enterprises
Developers will become more productive through close
integration with mature .NET Framework and CLR

Read
http://www.microsoft.com/sql/2005/productinfo/overview.
mspx
for a good overview of all the new features in SQL
Server 2005
44

© 2005 Project Botticelli Ltd & Microsoft Corporation. All rights reserved. This presentation is for informational
purposes only. PROJECT BOTTICELLI AND MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN
THIS SUMMARY. You must verify all the information presented before relying on it. E&OE.

Common questions

Powered by AI

SQL Server 2005 uses cryptography to protect data at rest by encrypting it with symmetric keys that are managed within the database security structure, including the Service Master Key and Database Master Key, which secure symmetric keys and ensure their availability for decryption operations . For data in motion, SQL Server 2005 employs SSL encryption to secure communications between clients and the server, while also supporting IPSec for encrypting network packets . A notable strength is the automatic generation of SSL certificates if none exist, reducing the burden on administrators to configure secure communications manually . However, a limitation is the performance overhead associated with encryption, especially when applied broadly . Furthermore, while efficient for specific operations, symmetric encryption keys alone do not offer the robustness needed to ensure complete protection, necessitating the integrated use of certificates and multifaceted key management practices .

Coding without base object access involves granting permissions solely to execute procedures, views, and functions without providing direct access to the underlying database tables or objects . This practice enhances security by encapsulating the business logic within controlled components, reducing the risk of unauthorized object manipulation or inappropriate data exposure . It leverages ownership chaining, allowing procedures within the same schema to access required data if they share the same owner, thus maintaining security without directly exposing sensitive objects to end users . By focusing access permissions on execution rather than direct data access, this strategy minimizes the attack surface and potential for SQL injection or privilege escalation .

SQL Server 2005's authorization model introduces user-schema separation, allowing multiple schemas within a database with distinct owning principals for more granular control . This separation enhances security by not requiring direct access to base objects but instead allowing permissions to be granted on procedures, views, or functions, often encapsulated within a schema . The EXECUTE AS clause further enriches this by enabling execution context changes, thus offering flexibility in granting permissions specific to operations without exposing base object access .

SQL Server 2005 employs several encryption techniques to protect data, focusing on using symmetric and asymmetric keys, and certificates. Symmetric keys are commonly used for encrypting data due to their efficiency and performance . They are usually encrypted themselves by the Database Master Key for added protection. Asymmetric keys and certificates are employed for additional layers of security, especially in signing modules and protecting sensitive operations . The Service Master Key (SMK) and Database Master Key (DMK) are integral to data encryption, ensuring that even if a database is moved or mirrored, the encrypted data remains secure provided the corresponding SMK and DMK are synchronized . SQL Server 2005 insists on double-encryption for enhanced security, though it recognizes this may slightly impact performance .

In SQL Server 2005, user-schema separation contributes to security and maintenance by allowing distinct schemas within a database, each owned by different principals. This separation enables precise control over object permissions and reduces the risk of unauthorized access since users can be restricted to execute specific routines without direct access to underlying base objects . It also simplifies maintenance by allowing changes to schema objects without disrupting operations or requiring extensive permission re-evaluation, as permissions are managed at the schema level rather than the object level . By encapsulating procedures and granting EXECUTE permissions at the schema level, SQL Server 2005 better isolates functionality from structural changes .

SQL Server 2005 addresses SQL injection by introducing several security enhancements and best practices. It emphasizes not trusting user input and recommends using parameterized queries over string concatenation to prevent arbitrary code execution . The implementation of the 'EXECUTE AS' clause allows for finer control over the execution context, which can mitigate injection risks by ensuring that dynamically constructed strings do not inherit elevated permissions from execution context . Additionally, SQL Server 2005 encourages using regular expressions to validate input, and recommends restricting error message detail and employing low-privilege accounts to minimize damage risks .

SQL Server 2005 enhances database availability through several features, including failover clustering and database mirroring, which provide redundancy and rapid recovery in case of server failures . It supports database snapshots that offer instant, read-only views for consistent state rollbacks or reads, minimizing data unavailability . Fast recovery capabilities allow database use even while rollbacks are in progress, ensuring continuity . Additionally, dedicated administrative connections assure database accessibility under duress, allowing for troubleshooting and recovery operations even when the system is under strain .

Service Broker in SQL Server 2005 plays a critical role in supporting Service-Oriented Architectures (SOA) by providing asynchronous message routing as a framework for applications . It enhances system functionality by enabling reliable messaging between databases and applications, which is essential for distributed systems that require decoupled data processing . This supports complex workflows and integrations among disparate systems, allowing for scalable and flexible system design . The Service Broker ensures message delivery integrity and offers built-in messaging priorities and conversation management, which simplifies integration tasks and improves the efficiency and reliability of service communications .

SQL Server 2005 ensures scalability through features like snapshot isolation, table and index partitioning, and 64-bit optimization . Snapshot isolation provides transactionally consistent views for operations on large datasets without locking, which enhances the handling of concurrent operations in OLTP systems . Table and index partitioning supports horizontal partitioning of large tables, making it more efficient to manage and query terabyte-sized datasets by reducing the load on single parts of a dataset at any one time . 64-bit optimization allows SQL Server to utilize improved memory addressing capabilities, which enhances the performance of data-intensive operations and allows for handling larger datasets efficiently . These features collectively address the challenges of managing large, complex databases by improving processing efficiency and reducing the resource constraints typically associated with large-scale operations .

SQL Server 2005 significantly improves developer productivity by integrating the .NET Framework and CLR, allowing developers to write stored procedures, functions, and triggers in .NET languages such as C# and VB.NET . This integration facilitates handling of tasks that were complex or unsafe in T-SQL, like using regular expressions or requiring extended stored procedures . The Business Intelligence Development Studio, based on Visual Studio, enables streamlined management of reporting, analysis services, and debugging, providing a cohesive development environment . The enhanced T-SQL also introduces recursive queries and better error handling, further supporting complex task management .

You might also like