>> Always Encrypted has had quite a journey with SQL Server,
Azure SQL Managed Instance,
and Azure SQL database.
In this episode, we're going to learn all
about those enhancements and how we're making it
more accessible with VBS enclaves in
Azure SQL database this week on Data Exposed.
[MUSIC]
Hi.
I'm Anna Hoffman and welcome to this episode of Data Exposed.
Today I have Pieter joining us again.
Welcome, Pieter, back to Data Exposed.
You've been on before for SQL Ledger,
we're having you back on for an exciting other topic.
But before we get into it, Pieter,
can you tell us a little bit about what you and your team do?
>> Yes. Sure. Hi Anna. My name is Pieter.
I'm a program manager in the data platform security team.
That's our team manages all the security features in Azure SQL,
Managed Instance, and SQL Server.
Yeah, like you said, I'm the PM
for Ledger and also Always Encrypted.
>> Awesome. Cool. These are two pretty hot topics.
Today we are going to be talking about Always Encrypted
with VBS enclaves in Azure SQL database,
something that is in public preview
today at the time of this recording.
Really exciting. But Pieter,
I just have to ask you before we get into VBS enclaves,
which I have no idea what that is,
can you back up and tell us
all about Always Encrypted and
the history of that with Azure SQL or in SQL Server?
>> Yeah, sure, of course.
What was our motivation?
We wanted to enable our customers to
confidentially store their most sensitive data in the Cloud.
We had TDE, we had TLS,
but that didn't really protect data that was in use.
We wanted to protect the sensitive data from
high privileged users but yet unauthorized users.
To give you an example,
in my previous life,
I was a DBA or a consultant.
I came to my customers and I could
literally see all the sensitive information.
Back then, we didn't have
any functionality or feature that supported that.
On top of that, we also wanted to have that the query processing
was still possible without
exposing the data to the administrators.
Back in the old days,
when we released SQL Server 2016,
we introduced Always Encrypted.
That was our first version,
it is also available in Azure SQL DB,
Managed Instance, and now even also in Cosmos DB.
What we're doing, so it's really client-side encryption,
which means that the client application is considered
trusted and everything outside
the application is considered as non trusted.
It's really the client driver that is going to encrypt and
decrypt the data and sends it
in ciphertext over the database engine.
With that version, the first version of Always Encrypted,
you got really strong encryption but unfortunately,
you were quite limited when you want to do
some computation on encrypted columns.
The only thing that you could do is, for example,
in a where clause on an encrypted column,
you could only use equality,
for example, which was not a lot.
You had a good encryption but you lose a lot of functionality.
We came up with a newer version of Always Encrypted
which is what we call Always Encrypted with secure enclaves.
What we're doing, the database engine is going to delegate
operations on encrypted data to an enclave, and an enclave,
I'll explain it immediately in the next slide,
but you should see it as a black box
where nobody actually has access to where
the engine can then safely decrypt and
process the data inside that specific enclave.
We're doing computation then,
not on encrypted information anymore but on plain text.
Which means, if we use secure enclaves,
now we have much more flexibility,
we could run confidential or rich queries,
we could use larger than,
smaller than in the WHERE clause,
we can use like,
we can do sorting,
and we can even create non-clustered index on encrypted column.
We get much more flexibility here.
On top of that, by using these enclaves,
we can also do in-place encryption,
which means for the initial encryption of a specific column,
when we use the first version,
we had to extract all the data to
the client side during
encryption and then push it back inside the database.
Now with enclaves, it's not necessary,
we can just use the enclave to do the initial data encryption.
Same for key rotation,
we don't need to move the data outside of the database anymore.
>> Nice.
>> That was what we wanted to have
and we wanted to give much more flexibility to our customers.
Now you're probably wondering, what is that enclave exactly?
Well, it's an isolated region of
memory where literally no process,
no human being, nobody has access to.
It's really a black box that is considered fully trusted.
But how do we guarantee that trust?
We have two possibilities?
Or you can use hypervisor which is what we call
virtualization-based security or VBS enclaves,
which is currently used for SQL Server,
so the box version.
You can also have a hardware enclave which is
called Intel Software Guard Extension or Intel SGX,
and that's really a CPU inside the server that
will guarantee the isolation of the enclave itself.
That is something that Intel SGX that
we're currently using in Azure SQL database.
If you want to use enclaves,
you have to use Intel SGX.
So our customers,
they will need to create
a specific hardware configuration
for that and that's what we call the DC-series.
When you do that, under the hood,
we're going to configure the virtual machine
with that specific CPU in site.
Which means you can use the enclave,
but as you can see here on my screen,
we have quite some limitations with that DCs series.
For example, you can go up to maximum eight vCores,
if our customers want to use more,
they need to go to Always Encrypted,
the first version, but then again they lose the flexibility.
The region availability is also quite limited,
so we just have East and West US,
Northern West Europe, Canada,
and UK South, and that's it.
On top of that, last but not least,
of course, DC-series are quite expensive to configure.
Now, Anna, what we did to address all these problems,
we've created a new version of Always Encrypted
which is Always Encrypted with VBS Enclaves.
It's software instead of hardware.
That is currently in public preview,
so customers, they can start in trying it out.
>> Okay, got you. Then,
if I was using this,
if it's using VBS, again,
I'm still new to this, do I need
a different hardware for that or how does that work?
>> No. That's the whole point of
VBS enclaves. Let me compare the two.
For SGX, you had to use a specific hardware, the DC-series,
VBS enclaves you don't need to have any specific hardware at all,
so there's no hardware dependency.
Which means, if you look at it,
the purchasing model,
in SGX we only support vCore,
with VBS enclaves you can go with DTU and vCores.
We also support serverless.
The limitation that we have for
the eight physical vCores in SGX is also gone.
You can go up to 128 vCores if you want.
It is available already in
public preview in all the Azure regions,
so we have no region limitations at all,
and it still protects you from the data.
It still protects you from rogue customers, DBAs, whatever.
It is the same encryption technology that we're using,
it's just a different version of the enclave that we have.
Now, the only difference that we see is that,
so it protects you from attacks from originating from
the guest operating system like
rogue collaborators malware but VBS enclaves does
not protect you from the host OS compared to SGX.
What does it mean is that if you do not trust Microsoft,
then you still need to go with
SGX enclaves and not VBS enclaves. You right?
>> Got that. Wow, this is really cool. I had no idea.
This basically opens it up to any customer of
Azure SQL database pretty
much because it's available in all the different tiers.
Is there an additional cost associated with this?
>> No. It's completely for free.
Even when we will go GA with this,
the security feature is completely for free.
You just configure a normal general-purpose database,
for example, you switch VBS enclaves on,
and you're good to go. No extra cost.
>> That is awesome. You're getting
to what I was going to ask next,
is, how do I set this up
and what else should I know as I get started?
>> Maybe one last thing on this,
Anna, if I may.
We're also investigating to improve the SGX enclave,
but stay tuned for that in a few months.
We're also going to have an update on SGX as well.
But yeah, good question.
How do you get started with this? Pretty easy.
We're currently supporting PowerShell commands and also Azure CLI.
The only thing you need to do when you want to create
a new database with VBS enclaves enabled,
you need to specify an extra parameter
called preferred enclave type and you just set it to VBS.
If you have already an existing database
and you want to try it out,
then you need to use the Set AzSqlDatabase command, and again,
the same parameter,
preferred enclave type,
just set it to VBS and then you're good to go.
That's it. That's how easy it is.
>> Nice. That's awesome, Pieter.
Thanks so much for coming on Data Exposed.
I learned so much.
I think our viewers did as well.
Viewers, you should go check this out.
It's in public preview, if you're using it,
it's super easy to get started.
One final question for you, Pieter.
Any other advice or any other messaging from
the security side you want to make sure
our viewers are aware about?
>> No. Just try it out I would say and if you have
any problems or if you have feedback for us, just let me know.
We're happy to jump into
a calling and help you guys out. No problem.
>> Awesome. Pieter,
again, thanks so much for coming on the show.
To our viewers, we're going to put a bunch of links
in the description for you to go learn more,
go contact Pieter and his team about it,
what you think about this feature and leave us a comment,
like this episode, go try it out,
and we hope to see you next time on Data Exposed. [MUSIC]