SQL Server Storage Engine : SQL Server Security

Fun with execution context switching

RobWalters — Wed, 21 Jun 2006 15:50:00 GMT

Having multiple users each owning various objects is commonplace in the database world. When one user wants to give access of their object to another user -- that’s when administration of databases gets rather interesting.

Consider the following SQL Server 2000 experience:

User Barney has a table of Rock and Roll hits
User Fred wrote a stored procedure that accepts a time period and returns a list of the hits of that year

In the current scenario, Fred needs at least SELECT access to Barney's table in order for the stored procedure to work. This seems like a logical administrative task.

Now suppose Wilma wants to use Fred's stored procedure. In SQL Server 2000, Wilma would need explicit access to Barney's table or Fred would have to own the table in order for Wilma to accomplish this. Now imagine trying to manage this for hundreds of users in an enterprise and you can see that managing all these permissions could be quite cumbersome unless we came up with some consistent strategy.

To help alleviate some of this administrative burden, SQL Server 2005 allows users the ability to specify the execution context of which an object like a stored procedure or user-defined function will run under.

Imagine in our scenario that Fred could say, when this stored proc executes, execute it under my credentials so that Wilma doesn't have to go and get permissions on everything within the stored procedure in order for her to use it.

In SQL Server 2005, this would be accomplished using EXECUTE AS OWNER. In fact there are four possibilities when it comes to changing the execution context. They are as follows:

EXECUTE AS CALLER – This will execute under the credentials of the caller. This is the same default behavior as in previous versions of SQL Server. I.e. when Wilma calls the stored proc, the proc runs under Wilma.

EXECUTE AS SELF – This will execute under the credentials of the user who last modified the stored procedure. In our scenario if Bam-Bam modified Fred's stored proc and Wilma called Fred's Proc, the proc would run under Bam-Bam.

EXECUTE AS ‘(insert name of login)’ – This will execute under the credentials of the login identified. In order for this to work, the user creating or modifying the stored procedure needs to have IMPERSONATE permission for the login specified. In our scenario if Fred wanted to run the stored proc under Dino's credentials, Fred would need the IMPERSONATE permissions granted to him by the sysadmin first, then he could EXECUTE AS 'Dino'.

EXECUTE AS OWNER – This will execute under the credentials of the login who owns the stored procedure. As explained previously, Fred's stored proc will be run under Fred regardless of who executes it.

Referring back to our example, let us write a few examples of execution context switching. To gain the most from this, it is best to walk through this line by line in your favorite TSQL editor or simply read through the comments.

-- Demo setup

-- create our logins, users and database

use master

create login BarneyLogin with password='!@w9Kfvn3'

create login FredLogin with password='MN3@8YU8u'

create login WilmaLogin with password='Nb29D%&2j'

create database Music

use Music

--Create our database users mapped to their login

create user BarneyUser for login BarneyLogin with default_schema=BarneySchema

create user FredUser for login FredLogin with default_schema=FredSchema

create user WilmaUser for login WilmaLogin with default_schema=WilmaSchema

--Create our schemas for each user

create schema BarneySchema

authorization BarneyUser

create schema FredSchema

authorization FredUser

create schema WilmaSchema

authorization WilmaUser

--Create a table that Barney's schema owns

use Music

create table BarneySchema.RockHits

(YearPublished int NOT NULL,

Title nvarchar(50) NOT NULL)

--Insert some data into the table

insert into BarneySchema.RockHits values('1960','Pebbles Jam')

insert into BarneySchema.RockHits values('1961','Dino Disco')

insert into BarneySchema.RockHits values('1961','Fred''s Dance Formula')

GRANT SELECT ON BarneySchema.RockHits to FredUser

--Create the stored procedure that Fred's Schema owns, remember

--EXECUTE AS CALLER is the same as SQL Server 2000 behavior

--The stored proc executes under whomever is calling it

create procedure FredSchema.ListHits

@Year int

WITH EXECUTE AS CALLER

BEGIN

select CURRENT_USER as '(Execute as Caller), Current User Context='

select YearPublished,Title from BarneySchema.RockHits where

YearPublished=@Year

END

--Let's grant Wilma the ability to execute this stored proc

GRANT EXECUTE ON FredSchema.ListHits to WilmaUser

--At this point we can begin playing with context switching

--We have given Fred access to Barney's table of hits

--We created the stored proc with SQL Server 2000 behavior i.e. EXECUTE AS CALLER

--We have given Wilma access to Fred's Stored Proc

--Lets begin by logging in as Fred and seeing if this stored proc works

execute as user='FredUser'

exec ListHits 1961

--The result is "Executing as FredUser" and the two titles from 1961

--A note on using executing as:

--We used "Execute as user='FredUser'" to context switch inline to

--The database user "FredUser", we could have used, "Execute as login='FredLogin'"

--However, this would have expanded the scope of the current connection to

--FredLogin e.g. this connection could not only use FredUser but could use any database user

--that was mapped to FredLogin! So its best to scope the context switch

--as narrow as possible, in our demo we only care about the database user FredUser within the Music database so we use execute as user.

--Now let's have Wilma try and execute the stored proc

REVERT --go back to sysadmin

EXECUTE AS user='WilmaUser'

exec FredSchema.ListHits 1961

--We get the SELECT permission denied error as expected

--because the stored proc is executing as WilmaUser

--Now let's ALTER the stored procedure so that it will run under

--its owner, Fred.

REVERT

ALTER PROCEDURE FredSchema.ListHits

@Year int

WITH EXECUTE AS OWNER

BEGIN

select CURRENT_USER as '(Execute as Owner), Current User Context='

select YearPublished,Title from BarneySchema.RockHits where

YearPublished=@Year

END

--Now let's try Wilma again

EXECUTE AS user='WilmaUser'

exec FredSchema.ListHits 1961

--As you can see the current user context is FredUser! and we didn't

--have to give Wilma explicit permissions to the underlying table in

--Fred's stored proc.

The previous example showed how one might leverage execution context switching with stored procedures. Have fun!

Side note: One of the things we have found recently is if you are switching to a domain user SQL Server needs to hit a domain controller so if the DC is offline, the command will fail. SQL Server doesn't cache domain credentials. We are looking into this issue.

Encryption 101

RobWalters — Mon, 19 Jun 2006 15:10:00 GMT

With the release of SQL Server 2005 comes a plethora of new security related features. Over time we will cover these in detail. To start, let's look at the world of encryption.

When it comes to protecting data we can take a mile high view of this problem and determine that we need to protect it while its in trasit (over the wire) and when its at rest (while stored on a physcial disk or memory). Some of you have probably read various stories about company laptop's being stolen that contain large amounts of sensitive information. This is a great example of the need to protect sensitive data stored at rest.

In previous versions of SQL Server (pre-2005), the server had limited features out of the box to protect data while in transit and had no native support to encrypt data within the database. (There are some third party vendors that added this type of functionality in SQL 2000).

Before we go into details on encryption, we should first go through some of the key concepts in this space. If you can already define words like "symmetric key" and "certificate", then you can skip ahead to the "Protecting data while in transit" section later in this post.

Encryption Primer:

Let's say I have a table of customer credit card numbers and I want to encrypt the credit card number column. In order to encrypt this text I need three things: an encryption key, an algorithm, and the actual text I want to encrypt. When we take the text and key and run the algorithm on it, we end up with what is known as ciphertext (the encrypted data).

"4428-0123-4567-8910" --Now becomes--> 0x01238EB28401AC0283...

There are two types of keys we will talk about in this blog: Symmetric and Asymmetric.

A symmetric key is a single key that is used for both encrypting and decrypting data. So if I wanted you to be able to decrypt my credit card list, I would simply give you the same symmetric key I used when I encrypted it. Now al you have to do is pass the encrypted ciphertext and key into the algorithm and voila you have the original plain text. Symmetric key encryption and decryption is fast relative to asymmetric keys, however, there are some important points to remember when using symmetric keys. What if as I was giving you the key someone saw the key and copied it? Now everytime I send you the encrypted credit card list, the attacker who has made a copy of the symmetric key can easily decrypt it and now we have a serious problem. So when we use symmetric key encryption we absolutely must protect the keys or else all of this encryption business is irrelevant. In SQL Server 2005 we do protect symmetric keys in two ways, via password and via encryption by another key. I will explain more in the "Protecting data while at rest" section.

An Asymetric key is essentially two keys: A public key and a private key. Both of these keys are mathematically similar so when something is encrypted using my public key I can decrypt it using my private key and vise versa. This allows me to give everyone in the world my public key and I can have them send me encrypted messages that can only be decrypted using my private key (which I don't give out to anyone and lock it under 100 feet of lead and cement, a couple guard dogs, boobie-traps, land-mines and whatever else I can use to protect it). This behavior works well for the web. When you request a connection over HTTPS: you essentially are requesting their public key to be used in decrypting the contents on their web pages.

A certificate is an asymmetric key with some extra metadata like an expiration date, the name of the certificate authroity that issued the certificate, etc. Having a third-party certificate authority issue you a certificate can be important depending on the size of your organization and how you are using the certificate. It basically gives users more confidence that the data they are receiving and sending to someone is actually coming from that person and not some impersonator.

The amount of algorithms available depend on which version of the operating system you are using. Each algorithm has pros and cons and if you are interesting in learning more about these, there is a ton of information on the web for further study.

XPSP2 supports DES, 3DES, RC2, RC4, RSA

Windows 2003 server supports DES, 3DES, AES128, AES192, AES256, RC2, RC4, RSA

I am just scratching the surface when it comes to introducing these topics, if you are interested there are bunch of good books out there that describe cryptography in great detail.

Protecting data while in transit in SQL Server 2005:

Using the SQL Server Computer Manager you can set your server to always encrypt connections. Likewise you can configure your client machines to always encrypt connections and whether or not to validate the certificate.

Regardless of whether you change either of these settings, all connection/authentication requests to SQL Server (both via SQL Authentication and Windows Authentication) that use the SQL Native Client APIs will always be encrypted no matter what the server or client setting is. This is because SQL Server creates a self-signed certificate upon installation and uses this to encrypt the connection request. Once the login credentials are passed and the connection is confirmed, the connection will return to clear text or encrypted (depending on if you required the connection to be encrypted or not).

Remember that there is a small performance hit anytime you decide to require all connections encrypted.

A note on the "Trust Server Certificate" option in the SQL Native Client properties dialog. As we discussed before, SQL Server issues a self-signed certificate. Since this certificate is not signed by a certificate authority it is not automatically trusted (like when you obtain a cert using Verisign, etc). You could get a signed certificate from one of the certificate authories and upload it to the server if you wish. This costs some cash though (because the certificate authories charge money for this service). So how you set this up depends upon how your organization is using SQL Server and its exposure to the outside world.

Protecting data while at rest in SQL Server 2005:

Here is where SQL Server 2005 has a lot of added value out of the box. In the primer section of this post I talked about the basic needs of encryption needing the text, the key and the algorithm. These actions of creating and managing keys have their own DDL in SQL Server as well as a few built-in functions like EncryptByKey() that make the work of encrypting data -- easy. You will though have to change some code in your application to make encryption work, there is no magic checkbox (yet) that says, "make this column encrypted" and everyone is happy. That is currently a mild pain point for some customers in the whole encryption discussion -- just take a few pain killers and continue reading.

The easiest way to demonstrate encryption is to run through a demo. In this example we have a user called, "HR_User" who needs access to the salary table.

CREATE LOGIN HR_Login WITH PASSWORD='SomeComplexPassword'

CREATE DATABASE ExampleDB

use ExampleDB

CREATE USER HR_User FOR LOGIN HR_Login

--Now we must create a Database Master Key for the ExampleDB. Database Master Keys

--are used so that SQL Server can encrypt the keys you created. To protect this key we

--supply a password

CREATE MASTER KEY ENCRYPTION BY PASSWORD='AComplexPassword'

--Create the table that will store sensitive information

--Notice we use a varbinary for our salary information

--This is because the ciphertext (encrypted data) is binary

CREATE TABLE SalaryInfo

(employee nvarchar(50),

department nvarchar(50),

salary varbinary(60))

--Give access to this table to HR_User so they can add data

GRANT SELECT,INSERT TO HR_User

--Create a Symmetric Key

--Encrypt the key with a password

--Give access to the key to HR_User

CREATE SYMMETRIC KEY HR_User_Key

AUTHORIZATION HR_User

WITH ALGORITHM=TRIPLE_DES

ENCRYPTION BY PASSWORD='CompensationPlansRule'

--Now, let's login as HR_User and encrypt some data

EXECUTE AS LOGIN='HR_Login'

--First, we need to open the key that will be used to encrypt data

--Notice we always have to pass the password for the key -- what a pain in the..

OPEN SYMMETRIC KEY HR_User_Key DECRYPTION BY PASSWORD='CompensationPlansRule'

--This system view shows a list of open keys that can be used for encryption

select * from sys.openkeys

--Now let us insert sensitive data into the table

--encryptByKey takes the GUID of the key and the text of the data

--Since remembering GUIDs is not easy, Key_GUID is a function

--that does the lookup for us

INSERT INTO SalaryInfo VALUES

('Bryan','Sales',encryptByKey(Key_GUID('HR_User_Key'),'125000'))

INSERT INTO SalaryInfo VALUES

('Tammie','Sales',encryptByKey(Key_GUID('HR_User_Key'),'122000'))

INSERT INTO SalaryInfo VALUES

('Frank','Development',encryptByKey(Key_GUID('HR_User_Key'),'97500'))

INSERT INTO SalaryInfo VALUES

('Fran','Marketing',encryptByKey(Key_GUID('HR_User_Key'),'99500'))

--When we are done, always close all keys

CLOSE ALL SYMMETRIC KEYS

--View the table as it lives in the database, notice the salary column is all binary

select * from SalaryInfo

--Now, let's decrypt and view the contents

--We use decryptByKey and pass the column name

--We don't have to specify a key GUID because SQL will look

--at all your open keys and use the appropriate one automatically

OPEN SYMMETRIC KEY HR_User_Key DECRYPTION BY PASSWORD='CompensationPlansRule'

SELECT employee,department,

CONVERT(varchar,decryptByKey(salary))

FROM SalaryInfo

CLOSE ALL SYMMETRIC KEYS

--Revert back to sysadmin

REVERT

--When encrypting by password, need to know the password

--and pass it everytime you encrypt something.

--Alternatively you can create a certificate and give access to

--the HR User. With this, the user doesn't have to provide a password

--and you can easily revoke access to that encrypted data by simply

--removing the cert

CREATE CERTIFICATE HRCert1

AUTHORIZATION HR_User

WITH SUBJECT='Certificate used by the Human Resources person'

--Open the key so we can modify it

OPEN SYMMETRIC KEY HR_User_Key DECRYPTION BY PASSWORD='CompensationPlansRule'

--We can not remove the password because we would leave the key

--exposed without encryption so we need to add the certificate first

ALTER SYMMETRIC KEY HR_User_Key

ADD ENCRYPTION BY CERTIFICATE HRCert1

--Now we can remove the password encryption from the key

ALTER SYMMETRIC KEY HR_User_Key

DROP ENCRYPTION BY PASSWORD= 'CompensationPlansRule'

CLOSE ALL SYMMETRIC KEYS

--Now change context to HR_Login to test our changes

EXECUTE AS LOGIN='HR_Login'

--Notice, we opened the key without a password!

--This is because we created the certificate and gave authorization

--on it explicitly to HR_User

OPEN SYMMETRIC KEY HR_User_Key DECRYPTION BY CERTIFICATE HRCert1

SELECT employee,department,

CONVERT(varchar,decryptByKey(salary))

FROM SalaryInfo

This post is meant to give an overview of encryption in SQL Server 2005. There are two members of the SQL Engine team, Laurentiu Cristofor and Raul Garcia who have blogs dedicated to supporting encryption in SQL Server.

For information on encryption check out these blogs:

http://blogs.msdn.com/lcris

http://blogs.msdn.com/raulga