Microsoft SQL Server 2012 Security Enhancements

Jack Richins - Senior SDE Lead

JACK RICHINS: Hi, I'm Jack Richins, and I'm presenting SQL Server 2012 Security Enhancements
today.

We'll be going over and reviewing features that were introduced in SQL Server 2008 to set the
context, and then reviewing new features that are being introduced in SQL Server 2012. Along
the way, you'll learn how you can use these features to better reach compliance in SQL Server
2012.

Let's start off with going over a recap of the 2008 features, and then the new features in SQL
Server 2012, namely manageability enhancements, audit enhancements, database
authentication, and cryptography changes for SQL Server 2012.

In SQL Server 2008, we had a very strong suite of security features that addressed areas in
protecting your data, controlling access, and ensuring compliance across your SQL Server
deployments with features such as transparent data encryption, extensible key management to
help protect your data at rest, Kerberos authentication enhancements to improve the security
as you were logging in and authenticating with the system. And SQL Server audit and change
data capture, policy-based management, and common criteria certification to help you reach
compliance.

This provided a strong security story for SQL Server 2008, as we provided you means to monitor
access to your data, and control access, and reach compliance through features such as
transparent data encryption, auditing, and monitoring whether those features were on or off
through policy-based management. We allowed you greater control over your key management
through extensible key management, and audit and authorization provided granular control
over who had access, and an audit log of who was exercising that access. Login triggers and SSL
further protected connections of applications to the SQL Server data stores and remote backup
allowed compliance and risk management of protecting your data assets.

So, let's talk about what's new in security in SQL Server 2012.

We've improved manageability of security in SQL Server 2012 with features such as default
schema for groups, and user defined server roles.

Default schemas for groups is a new feature in 2012, and a long-standing ask and connect for
SQL Server. Previously, you could only define a default schema for an individual user. Now, you
can assign a default schema to a group. This eases administration and avoids implicit schema
creation, and implicit user creation. It reduces the chances of the wrong schema being used in
queries, and reduces the number of users that need to be maintained and monitored.

We've also introduced user-defined server roles. A server role is a server-level principle, kind of
like a server group that the administrator can define. It's a collection of principles that hold a
collection of permissions. This can be compared to fixed server roles where it's a securable
class, and the permissions can change, so you can have different permissions that match your
compliance needs. It increases the flexibility, and manageability, and facilitates compliance.
Previously we had database roles, and these are much the same. It allows customers to define a
role, grant it permission such as control server, and deny it other permissions, such as alter any
login.

Here I'm connected to SQL Server 2012. I'm going to create a new server role called XEadmins.
This role is intended to provide a means of administering Xevent, a new feature in SQL Server
2008, and one that's been greatly enhanced in 2012. So, let's create that role, and grant it alter
any event session, and view server state, so that it can both monitor the system and create
event sessions.
Now I'm going to create a login to demonstrate using this. I'm going to add that login to the role
with the alter server role DDL statement. Now, I'm going to switch and use the UI. If you look
over under the database node, under management, there is a UI now around extended events.
I'm going to expand that so that there are a couple of sessions there.
Right now, I'm connected as Redmond/JackR, an administrator on the box. But I can create a
new database connection as the user I just defined, Bob. So, let's connect using Bob, and let's
see what he can do. If I go under the security, and try and do something like create a new login,
which Bob lacks the authorization for, I'll get the UI. But if I try and click okay, I will get an error
saying that I do not have permission to do this.
However, if I go under the management tab, and go down to extended events, we'll find that I
can start and stop sessions. I can create new sessions. I can use a template using the UI, add
any events that are interesting, determine which data I want to collect, review and add any
filtering to these fields that I want, determine how I want to collect the information, and then
have it go and create it. I can even view the data that's being collected in this nice UI.
So, let's stop that and drop that session. I have just demonstrated that I can use flexible server
roles to define a role that has a constrained set of capabilities. In this case, administer Xevents.
And I was able to add my own user to that account, and that user was now able to administer
Xevents.

We also paid a lot of attention to audit in SQL Server 2012, adding support for all SKUs,
improved resilience for the audit log, user-defined audit events, and reporting and record
filtering. We also record TSQL stack information for repudiation of the audit log events.

Audit is now available on all SKUs. The basic core audit functionality includes server audit
specifications. This is available only on -- the server audit specifications are available on all
SKUs, but we reserve the database audit specs, which include the granular audit capabilities, for
enterprise and data center. This means that you no longer need to depend on SQLTrace across
your enterprise. You can enjoy the basic advantages of audit across all of your SKUs from
Express through Enterprise, which include performance, multiple audit targets, persistent state,
and audit resilience of the audit logs.

In SQL Server 2008, we only had two options for handling errors when writing to the audit logs.
One was to ignore the errors, this could result in silently losing audit records. The other option
was to shut down the entire SQL Server instance on the first encounter of an audit log error.
This hurt availability. This forced customers to make bad compromises.
Now, we've improved our ability to self-record from many file and network errors. And we've
added a new option to handle failures for the auto log. And we've also added max files options
to better control usage of the audit logs.
So, let's discuss this new failure operation mode. Let's say the customer performs a select and
we attempt to write that to an audit log. We encounter an error. What will happen now is that
we will roll back the select transaction so that the audited operation does not take place, but
other operations that do not require auditing are allowed to proceed. This provides maximum
availability, along with maximum assurance that all required events are being recorded in the
audit log.

We have also included TSQL Stack information. Let's say a customer is executing a stored
procedure, such as view salary. Inside that it goes and does a select from the payroll table. In
the audit log when we audit the select on the payroll information, we will see that this is not an
ad hoc select from payroll, but indeed a call from the stored procedure. This provides you
guarantees that access was done through not directly, but is being done through business logic
encapsulated in your stored procedures.

We've also added user defined audit events. This allows customers to provide their own audit
events that express information in their business logic. An example of this is you can define
your own audit event number for you own filtering and record keeping, a success or failure bit
and then any arbitrary string to express the business logic of what this audit event represents.
So, the first parameter is the event ID, this is user defined. The success bit, and then the userdefined information. We also record the date and time. It will all show up underneath the same
action ID, but you can filter it using the user-defined event ID.

We've also added record filtering to SQL Server audit. This tightly constrains the information
that's written to the audit log. The audit record is generated, but it's not written. So, in this
respect it's not as performant as the granular audit filtering and the database audit spec. But, it
is more expressive in that you can filter on any column in the audit record and it is very
performant, as it leverages Xevent filtering.

Let's demonstrate some of these enhancements, namely, the user defined audit event. For this
demonstration I'm going to be creating a user-defined authentication, meaning that we have a
middle-tier that's connecting to the back end directly using a service account. But, then it
passes in a username and password hash, which we compare against a table inside the database
engine. So, this is application level authentication.
As part of this, I'm going to be storing an audit record in the backend in my SQL Server database
audit that requires the result of that authentication. So, let's create the database. Let's create
the database, use that database, create a schema for the application. Now, I'm creating the
accounts table inside that schema and inserting two users into that accounts table. Here I have
a stored procedure that establishes the application level identity.
I pass in the name and the password hash that's generated at the client layer. Then I will check
the table, using a select statement to see if that name exists. I'll set the result of the compare
and then I will write a user-defined audit event that gives the result of that. Now, let's go and
configure an audit to capture this information. So, I go to the security node down to audits. I
already have an audit set up. Let's review its configuration. This is just a basic audit, no filters
defined on this and it's going to go to a file target.
Let's turn that on. And I have a server audit specification here. Let's see how that's configured.
Right now it's auditing authentication at the database level and logouts and I'm auditing this
new user defined audit group. Let's enable that. Now, let's do a test authentication. Here I'm
emulating the application trying to connect and I successfully connect there. Now, I'm going to
do a failed connection and I get back a zero there. If we go and look at the audit log we can see
these events here. We see the user defined audit event. If we come over here you can see the
new fields here. Here's the TSQL stack information, which lets me know that this was not an ad

hoc user-defined audit event, but indeed went through my stored procedure for establishing
identity. And we can see the user-defined event IDs, and the information from that stored
procedure that's user defined, namely the name of the web user that tried to authenticate.
We can also see the success result. One succeeded and one failed. So, that's user-defined
auditing. Let's take a look at audit filtering. Here I'm going to go back to master. I'm going to
look up at my own principal ID. A common request is to either filter so the audits do not show
sys admin activity, or they only show sys admin activity. In this case I'm going to create an audit
event, or an audit filter so that my actions are ignored and do not show up as part of the audit
log. I'm going to create a server audit and as part of it I define a filter where the server principle
ID does not match my own. I'm going to turn this audit on. Now, I'm going to create an audit
specification so that I capture all failed log in events, successful log ins, log outs, and userdefined audit events.
Now, if I create a new query, logging in as myself, what we will see in the audit log that has been
filtered is no events. However, if I change my connection and log in as a different user we will
see activity from that account.
So, this is an example of SQL Server 2012 audit filtering. As I said before, these filters can be
defined on any field in the audit log and I think this is a feature that you will find quite useful.

Let's discuss database authentication now. This is new with contained databases, and it was a
feature that was designed not only for contained databases, but for use with always on. This
allows authentication without logins. You can do this either with SQL users, with passwords, or
Windows authentication without a log in. This makes it easier for deployment for contained
applications and tightly scoped security boundary, where you're giving no more access than is
absolutely necessary.

With the SQL user, with the user name and password, the connection string provides a user
name and a password and an initial catalogue. If you name an initial catalogue that's just a
normal database, you get a traditional log in. If you name a contained database and a user with
that name exists we will always attempt to do a contained use authentication. If a user exists
with that name, but a different password it will fail. If there is no user with that name we will
fall back to master and check to see if there is a log in there. We did this to provide maximum
backwards compatibility for as many customer scenarios, et al, so that there's minimum impact
to connection strings for your existing applications.

With Windows users, if you name a normal database as the initial catalogue you continue to get
a full log in. If a log in exists you will get all the permissions of that log in, even if you name an
initial catalogue that is a contained database. However, if there is no log in, but there is a user
in the contained database, then you will get a contained user token.

So, let's do a quick demonstration of SQL Server contained database authentication. I've already
on this database instance, or this SQL Server instance, enabled contained database
authentication. It is off by default so that people don't have to be concerned about a security
environment changing on them just by mere fact of upgrading. But, in this case I want
contained database authentication. So, I've enabled it on the server under advanced properties.
Under this containment enable contain databases. So, that's already been set.
Now, I'm going to create a contained database with partial containment. I'm going to use that
database and create an account for a local Windows group. I'm going to add this Windows
group to a couple of database roles, create a schema for it, and set the default schema for this
Windows group, create a table in that schema, and insert a few values into it.
Now, let's go back to master here for a second and now I'm going to log in as a contained user
that's a member of that Windows group. So, as you can see I'm now logged in as a contained
user, Bob, into CDB1. I cannot see other databases. I only have access to this one database, but
within that database I can attempt several things. I can try and execute system procedures, and
anything that's allowed to public users I'm allowed to do. But, I cannot, for example, change
settings. If I try and query sessions all I will see are the accounts I have access to, because I'm a
contained user.
I can look at the table I have access to. I can insert values and do everything that was intended.
While keeping that connection open, let's look at how you can monitor and manage these
accounts. So, as an administrator if I log in and query these accounts I can see this contained
user. If you go all the way over here we have some new fields in here, authenticating database
ID. So, I can see which database, different connections are in, and I can see where they
authenticated. For traditional logins the authenticating database is always master, for system
connections there's no authentication that happens. These are just system sessions. So, they
have no authenticating database. Everyone else has master and contained users will have the
database they authenticated against.
This information is all available within login triggers. So, this gives me a lot of flexibility in
controlling and managing contained database authentication. Let's go quickly to find a login

trigger. I'm going to create a table that allows me to turn on and off different databases. I'm
going to grant select to public, but retain right permission to myself.
So, I'm going to insert master into here. I'm going to create a trigger that's going to check
whenever a login tries to take place. It will check where it's authenticating and if it's not one of
the allowed databases it will roll back and fail that authentication. Now, if we go back to Bob, if
he tries to create a new connection he will be denied due to trigger execution. That's fine. All I
have to do as an administrator is go in and add him to this lookup table, and try again, and now
I'm in.
So, that's an example of how you could use triggers to granularly control contained users. One
other mechanism that you can do is keep track of who might be able to authenticate. On our
team blog we've documented a stored procedure that would allow you to do this. It's called all
authenticatable users. It checks all the server principles and then finds all the contained
databases and iterates over each of them and find the user accounts that could be used to
authenticate.
So, let's go ahead and create that, and it's already created here. Now, let's execute that stored
procedure and you'll see right now there are several logins on the system and there's one
contained database and there is one account that can get into that contained database. So, this
would be a good mechanism to monitor and keep track of all of the accounts that have access to
your contained databases, and to your SQL Server 2012 instance.

So, that's SQL Server contained database authentication.

We've also made some cryptographic changes to try and keep up with the times and ahead of
attackers. For greater flexibility in moving certificates around, we've added DDL to allow you to
create certificates from bytes. We've added support for 4K certificates for import. We've
changed the default for our service master key and database master keys to AES 256 encryption.
We've added key backups support so that they are now encrypted with AES 256 and we've
added SHA-2 256 and 512 support. Password hashes now use SHA 512 by default. This will
happen automatically as new passwords are added to SQL Server 2012. And we've deprecated
RC4 support.

For those of you that would like more information about these enhancements and others, I'd
like to refer you to several of these resources and books online, under SQL Server 2008 security
and SQL Server 2012 security. Additionally, check out the SQL Server Engine Security Blog and
the SQL Server Security Forum.

Thank you and I hope you have enjoyed learning about security enhancements in SQL Server
2012.

END