1
00:00:00,000 --> 00:00:09,700
Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy,

2
00:00:09,700 --> 00:00:13,280
reliability and compliance on the Microsoft Cloud Platform.

3
00:00:13,280 --> 00:00:17,460
Hey everybody, welcome to episode 87.

4
00:00:17,460 --> 00:00:21,300
This episode is actually one of those special episodes you do once in a while, where we're

5
00:00:21,300 --> 00:00:25,720
going to talk about something that is released into general availability or some new feature

6
00:00:25,720 --> 00:00:27,220
that's coming out.

7
00:00:27,220 --> 00:00:30,800
And this time around, we're going to talk about two new cryptographic controls or two

8
00:00:30,800 --> 00:00:36,560
updated cryptographic controls, I should say, in both Azure SQL Database and SQL Server.

9
00:00:36,560 --> 00:00:39,840
We're going to talk about the pros and cons of each of them and basically what the changes

10
00:00:39,840 --> 00:00:40,840
are.

11
00:00:40,840 --> 00:00:44,920
And this week we have two program managers who basically own these features.

12
00:00:44,920 --> 00:00:45,920
We've got Peter.

13
00:00:45,920 --> 00:00:48,760
Peter's been on the podcast twice now.

14
00:00:48,760 --> 00:00:49,960
And we also have Merrick.

15
00:00:49,960 --> 00:00:54,760
And so Peter is the PM for Always Encrypted and Merrick is the program manager for Transparent

16
00:00:54,760 --> 00:00:55,760
Data Encryption.

17
00:00:55,760 --> 00:01:00,680
So before we get stuck into the actual, you know, what's changed, gentlemen, why don't

18
00:01:00,680 --> 00:01:01,680
you introduce yourself?

19
00:01:01,680 --> 00:01:03,360
Merrick, why don't you kick things off?

20
00:01:03,360 --> 00:01:05,680
So hello everybody.

21
00:01:05,680 --> 00:01:10,320
My name is Merrick and I'm a PM in the Azure SQL Security Team.

22
00:01:10,320 --> 00:01:18,840
I have worked with SQL since SQL 2000, mostly in the storage engine, access method, metadata,

23
00:01:18,840 --> 00:01:24,280
releasing features that probably most of you know, like snapshot isolation, online index

24
00:01:24,280 --> 00:01:32,280
and recently from the metadata or from the security standpoint, the Microsoft Entra ID

25
00:01:32,280 --> 00:01:38,760
that for your information, that was the former Azure Active Directory that was changed.

26
00:01:38,760 --> 00:01:40,560
The name was changed.

27
00:01:40,560 --> 00:01:47,400
And there was the implementation of the Entra across the whole Azure SQL, finally adding

28
00:01:47,400 --> 00:01:56,840
with the SQL Server 2022 that allows the connection to Azure SQL databases from SQL Server.

29
00:01:56,840 --> 00:02:01,760
And now I'm part of the Transparent Data Encryption Team, TDE.

30
00:02:01,760 --> 00:02:09,280
And I would like to let you know about the latest innovations, features that were released

31
00:02:09,280 --> 00:02:12,760
in this area, in the TDE area.

32
00:02:12,760 --> 00:02:22,480
The TDE is the encryption data addressed and it protects user data.

33
00:02:22,480 --> 00:02:30,640
So it protects the whole database, protects the transaction locks, the GoDR, the tempDB.

34
00:02:30,640 --> 00:02:39,600
It doesn't protect masterDB because we allow customers to use masterDB as this key part

35
00:02:39,600 --> 00:02:43,440
of the database or server that has to be used.

36
00:02:43,440 --> 00:02:46,880
The TDE has two levels.

37
00:02:46,880 --> 00:02:55,780
The first one is the database encryption deck that is available to encrypt the whole database.

38
00:02:55,780 --> 00:03:02,720
And then there is the deck protection, the TDE protector that allows this.

39
00:03:02,720 --> 00:03:09,280
And we have two options for this deck protector, either using the system manage key or the

40
00:03:09,280 --> 00:03:11,040
customer manage key.

41
00:03:11,040 --> 00:03:17,360
In the latest development that we made and released, the focus was on the customer managed

42
00:03:17,360 --> 00:03:26,600
key that is using AKV, Azure Key Vault, and offers the policy for customers to manage

43
00:03:26,600 --> 00:03:32,360
the key, to allow permissions to the key, to rotate the key, to use the key across the

44
00:03:32,360 --> 00:03:33,360
tenant.

45
00:03:33,360 --> 00:03:37,560
And that's kind of the main focus.

46
00:03:37,560 --> 00:03:43,720
And the reason for this is the following, that more customers, especially in the financial

47
00:03:43,720 --> 00:03:51,320
sector, in the money market sector, in the banking, they want to have access to their

48
00:03:51,320 --> 00:03:55,120
keys in terms of they want to own the key.

49
00:03:55,120 --> 00:03:57,600
They want to give the proper access.

50
00:03:57,600 --> 00:04:02,800
They want to make sure that the policies are really defined by them.

51
00:04:02,800 --> 00:04:09,800
So many customers just decide to use the customer managed key and created the Azure Key Vault.

52
00:04:09,800 --> 00:04:17,840
There's one more important part that we need to know when we talk about the underlying

53
00:04:17,840 --> 00:04:18,940
storage.

54
00:04:18,940 --> 00:04:24,960
We have two types of storage that Azure offers today, which is the remote storage and there

55
00:04:24,960 --> 00:04:27,000
is a local storage.

56
00:04:27,000 --> 00:04:33,000
Now the remote storage is encrypted, which means that the data there, the data is at

57
00:04:33,000 --> 00:04:39,760
rest, is encrypted and protecting through accessing this data.

58
00:04:39,760 --> 00:04:48,280
So when we put on the top the TDE for certain additions like basic, standard, general purpose

59
00:04:48,280 --> 00:04:52,840
or hyperscale, we can see so-called double encryption.

60
00:04:52,840 --> 00:04:58,240
One is coming from the Azure storage and one is coming from TDE.

61
00:04:58,240 --> 00:05:06,680
However, if the customer is using a local storage and this is that applies to the premium

62
00:05:06,680 --> 00:05:11,440
and business critical, this storage is not protected.

63
00:05:11,440 --> 00:05:18,440
So if for some reason the customer doesn't choose to use TDE because it's possible to

64
00:05:18,440 --> 00:05:26,840
disable it, there is a big danger that there's a fact that the data is not protected and

65
00:05:26,840 --> 00:05:36,640
as a data of rest can be accessed by potentially by malicious groups to do this.

66
00:05:36,640 --> 00:05:46,400
So that's why we always encourage customers to use the TDE and ideally to use the AKV

67
00:05:46,400 --> 00:05:54,760
because that gives all these options to manage the key and to be the owner of the key.

68
00:05:54,760 --> 00:06:05,560
So in the latest releases, what we have added to the general, to the TDE is the key rotation.

69
00:06:05,560 --> 00:06:12,560
As you know, when the key is created for CMK, for customer managed key, it has a special

70
00:06:12,560 --> 00:06:13,560
version.

71
00:06:13,560 --> 00:06:20,840
Now, the AKV offers an opportunity to change these versions periodically.

72
00:06:20,840 --> 00:06:27,560
And the reason for this is again protection that the customer protects this key and whoever

73
00:06:27,560 --> 00:06:34,560
has access to the past key will not be able to use the database because the key was rotated,

74
00:06:34,560 --> 00:06:36,800
the new version was created.

75
00:06:36,800 --> 00:06:48,920
So this key versioning or the key rotation was added to the entire TDE, but specifically

76
00:06:48,920 --> 00:06:55,840
it was also added to another granularity that we offer, which means we offer a possibility

77
00:06:55,840 --> 00:07:00,320
to add the CMK at the database level.

78
00:07:00,320 --> 00:07:08,840
In the past, the TDE had a CMK defined at the server level, which means all databases

79
00:07:08,840 --> 00:07:13,680
underneath use the same key, use the same CMK key.

80
00:07:13,680 --> 00:07:22,240
However, with the recent release that was available in GA, general availability in September

81
00:07:22,240 --> 00:07:30,760
and is ready to go, we offer this other granularity, which means we allow to specify the key at

82
00:07:30,760 --> 00:07:33,400
the database level.

83
00:07:33,400 --> 00:07:36,920
And I'll come in a moment why this is so important.

84
00:07:36,920 --> 00:07:41,840
And then not only this, we allow to rotate these keys and we allow to create these keys

85
00:07:41,840 --> 00:07:43,840
in another tenant.

86
00:07:43,840 --> 00:07:52,840
So this particular feature is very interesting for ISVs that provide the elastic pools.

87
00:07:52,840 --> 00:07:56,400
The scenario that you have around this is the following.

88
00:07:56,400 --> 00:08:01,320
You have in the elastic pool, you have typically one server, but there are multiple databases,

89
00:08:01,320 --> 00:08:05,480
many databases, and they belong to different customers.

90
00:08:05,480 --> 00:08:11,040
Potential security issue is that customers may be worried that they would share the same

91
00:08:11,040 --> 00:08:15,000
key with other customers if this is at the server level.

92
00:08:15,000 --> 00:08:21,360
So if the customer chooses to use the database level and on the top of this chooses that

93
00:08:21,360 --> 00:08:30,640
I want to create my key, my AKV in my tenant, that is a different tenant that serves the

94
00:08:30,640 --> 00:08:35,220
server itself, that allows a customer to get a full control.

95
00:08:35,220 --> 00:08:40,080
So customer can create a key there, its own key can set up the rotation.

96
00:08:40,080 --> 00:08:46,160
Obviously, there's a setup needed between these two, between the server in one tenant

97
00:08:46,160 --> 00:08:51,040
in server tenant and then the setup in the customer tenant.

98
00:08:51,040 --> 00:08:56,360
And this is done through the multi-tenant application with a federated identity.

99
00:08:56,360 --> 00:09:04,240
But once this is done, customer accesses its own databases using its own key and it cannot

100
00:09:04,240 --> 00:09:11,640
be accessed by other owners, by other databases, because this is a different key.

101
00:09:11,640 --> 00:09:20,320
So in summary, first of all, if I can close with a few sentences, make sure that your

102
00:09:20,320 --> 00:09:24,760
database is always protected with the TDE and there are ways to check it.

103
00:09:24,760 --> 00:09:33,360
You can use the DMVs like sysdm-encryption or sysdb-loginfo, where you can see if the

104
00:09:33,360 --> 00:09:35,080
database is encrypted.

105
00:09:35,080 --> 00:09:36,700
This is very important.

106
00:09:36,700 --> 00:09:43,720
And the second one, choose the right level if the server level granularity for CMK is

107
00:09:43,720 --> 00:09:50,800
the right for you or if the database level CMK with all these benefits that I mentioned

108
00:09:50,800 --> 00:09:56,720
just fits nicely to you, to your need and to your scenario.

109
00:09:56,720 --> 00:10:00,760
So that's kind of the summary from my end.

110
00:10:00,760 --> 00:10:04,200
From my perspective, some people understand this.

111
00:10:04,200 --> 00:10:10,000
So one of the big changes there is the fact that you can now encrypt using TDE at the

112
00:10:10,000 --> 00:10:14,160
database level but have different keys per database.

113
00:10:14,160 --> 00:10:15,160
That's what you're saying.

114
00:10:15,160 --> 00:10:17,760
So historically, we only did it per database server.

115
00:10:17,760 --> 00:10:22,920
So if you had 27 databases underneath that, then they'd all be encrypted with the same

116
00:10:22,920 --> 00:10:25,880
TDE data encryption key, the DEC.

117
00:10:25,880 --> 00:10:31,080
But what we now offer is the ability to have a different set of encryption keys that are

118
00:10:31,080 --> 00:10:32,920
used at a per database level.

119
00:10:32,920 --> 00:10:36,160
So you may have a customer on database one and a customer on database two and a customer

120
00:10:36,160 --> 00:10:37,600
on database three.

121
00:10:37,600 --> 00:10:40,600
And now they have their own encryption key.

122
00:10:40,600 --> 00:10:41,600
Is that the case?

123
00:10:41,600 --> 00:10:42,600
Yes.

124
00:10:42,600 --> 00:10:48,960
And again, this is specifically important for the ISVs with the elastic pools who offer

125
00:10:48,960 --> 00:10:51,440
this type of services to customers.

126
00:10:51,440 --> 00:10:52,440
Perfect.

127
00:10:52,440 --> 00:10:53,440
All right.

128
00:10:53,440 --> 00:10:55,480
So now we've got TDE out of the way.

129
00:10:55,480 --> 00:10:58,960
Let's switch our attention to always encrypted.

130
00:10:58,960 --> 00:11:03,040
As I mentioned earlier, Peter, we've already had Peter on the podcast a couple of times.

131
00:11:03,040 --> 00:11:04,040
Nice to see you back, Peter.

132
00:11:04,040 --> 00:11:08,280
Do you want to just give a brief introduction about yourself and then go through the new

133
00:11:08,280 --> 00:11:10,080
changes to always encrypted?

134
00:11:10,080 --> 00:11:11,080
Sure.

135
00:11:11,080 --> 00:11:12,680
Hi, everyone.

136
00:11:12,680 --> 00:11:13,680
My name is Peter.

137
00:11:13,680 --> 00:11:18,660
I'm a program manager just like Birik in the Azure Data Platform Security Team.

138
00:11:18,660 --> 00:11:24,320
So that's the team that manages all the security features in Azure SQL and SQL Server.

139
00:11:24,320 --> 00:11:28,640
And I'm the PM for two features, Ledger, which we're not going to talk about.

140
00:11:28,640 --> 00:11:31,360
And I'm also the PM for always encrypted.

141
00:11:31,360 --> 00:11:37,040
And yeah, that's what we're going to talk about today and what new investments we have

142
00:11:37,040 --> 00:11:40,240
done the past couple of months.

143
00:11:40,240 --> 00:11:42,920
Maybe a short introduction, what always encrypted is.

144
00:11:42,920 --> 00:11:51,060
So the motivation of creating always encrypted is actually to enable our customers to store

145
00:11:51,060 --> 00:11:54,920
confidential information in the cloud.

146
00:11:54,920 --> 00:11:59,580
So it's not like TDE where we completely going to encrypt a database.

147
00:11:59,580 --> 00:12:02,320
It's really encryption on column level.

148
00:12:02,320 --> 00:12:08,880
For example, like DBAs, hackers, malware, they will never be able to see that confidential

149
00:12:08,880 --> 00:12:11,060
information.

150
00:12:11,060 --> 00:12:16,920
So we started our journey with always encrypted back in 2015.

151
00:12:16,920 --> 00:12:22,480
And the first version was released in SQL Server 2016 and is still available in the

152
00:12:22,480 --> 00:12:24,020
later versions.

153
00:12:24,020 --> 00:12:27,200
It is also available in Azure SQL DB and managed instance.

154
00:12:27,200 --> 00:12:32,700
And on top of that, last year, we also released always encrypted in Cosmos DB.

155
00:12:32,700 --> 00:12:37,800
So like I said, it really protects your data in use from malicious DBAs, operating system

156
00:12:37,800 --> 00:12:39,240
administrators and malware.

157
00:12:39,240 --> 00:12:44,820
So it's only the application side that is considered as trusted.

158
00:12:44,820 --> 00:12:51,240
Anything outside the application like the network, the database engine is completely

159
00:12:51,240 --> 00:12:54,640
is considered as non-trusted.

160
00:12:54,640 --> 00:12:59,840
So it's actually the client driver on the application side that is going to encrypt

161
00:12:59,840 --> 00:13:05,720
that sensitive information, send it in ciphertext over the network to the database engine.

162
00:13:05,720 --> 00:13:10,560
The database engine returns that information in ciphertext and then the client driver again

163
00:13:10,560 --> 00:13:13,260
is going to decrypt that information.

164
00:13:13,260 --> 00:13:17,320
That was the first version called always encrypted.

165
00:13:17,320 --> 00:13:18,720
Was a good version.

166
00:13:18,720 --> 00:13:25,060
However, there were some limitations related to flexibility and usability.

167
00:13:25,060 --> 00:13:30,960
For example, if you wanted to use an encrypted column in a where clause, that was possible,

168
00:13:30,960 --> 00:13:35,680
but you could only use equality, larger than smaller than for example, that was not even

169
00:13:35,680 --> 00:13:36,680
possible.

170
00:13:36,680 --> 00:13:40,760
And on top of that, you had to use deterministic encryption.

171
00:13:40,760 --> 00:13:44,760
So which is not as strong as randomized.

172
00:13:44,760 --> 00:13:51,320
So what we did, we came up with a newer version, which is called always encrypted with secure

173
00:13:51,320 --> 00:13:59,920
enclaves that was introduced in SQL Server 2019 and is also available in Azure SQL database.

174
00:13:59,920 --> 00:14:05,800
And so what we're doing, so when processing SQL queries, the database engine delegates

175
00:14:05,800 --> 00:14:09,880
computation on encrypted data to a secure enclave.

176
00:14:09,880 --> 00:14:14,840
The enclave then decrypts the data and performs computation on plain text.

177
00:14:14,840 --> 00:14:19,360
And this can be done completely safely because the enclave is, yeah, you should consider

178
00:14:19,360 --> 00:14:26,000
it as a black box and where nobody has actually access to the not the operating system, again,

179
00:14:26,000 --> 00:14:27,440
not the DBAs.

180
00:14:27,440 --> 00:14:30,520
Nobody can get inside that enclave.

181
00:14:30,520 --> 00:14:36,800
Now by leveraging that secure enclave, always encrypted can now support rich confidential

182
00:14:36,800 --> 00:14:37,800
queries.

183
00:14:37,800 --> 00:14:44,160
We can now use larger than smaller than we can use like we can use ordered by on an encrypted

184
00:14:44,160 --> 00:14:48,200
column, we can even create an index on an encrypted column.

185
00:14:48,200 --> 00:14:53,540
And on top of that, an extra advantage that you have by using these enclaves is in place

186
00:14:53,540 --> 00:14:54,940
encryption.

187
00:14:54,940 --> 00:15:00,400
So we don't have to move the data outside of the database to do your initial encryption.

188
00:15:00,400 --> 00:15:05,520
We can just use the enclave for that compared to the older version, always encrypted where

189
00:15:05,520 --> 00:15:10,680
we had to extract the data outside of the database to the application, do the encryption

190
00:15:10,680 --> 00:15:12,640
and then push it back in.

191
00:15:12,640 --> 00:15:16,080
So these were the two flavors that we had.

192
00:15:16,080 --> 00:15:20,160
So always encrypted and now always encrypted with secure enclaves.

193
00:15:20,160 --> 00:15:26,860
Now if you wanted to use secure enclaves in Azure SQL database, you have to configure

194
00:15:26,860 --> 00:15:30,760
a specific type of database called the DC series.

195
00:15:30,760 --> 00:15:36,720
And the DC series, when you configure that we're going to configure a specific hardware

196
00:15:36,720 --> 00:15:44,640
under the covers, which contains an Intel software guarded extension CPU or SGX that

197
00:15:44,640 --> 00:15:47,280
is used to secure that enclave.

198
00:15:47,280 --> 00:15:50,800
So we're literally using hardware under the covers for that.

199
00:15:50,800 --> 00:15:56,820
The problem between brackets was that when you configured DC series, you had the limitation

200
00:15:56,820 --> 00:15:59,360
up to a maximum of eight V cores.

201
00:15:59,360 --> 00:16:05,640
And yeah, I'm happy to announce Michael that today we're releasing the general availability

202
00:16:05,640 --> 00:16:12,600
for SGX enclaves or the DC series up to 40 V cores instead of eight.

203
00:16:12,600 --> 00:16:17,560
This allows our customers that have a high demand of CPU and memory.

204
00:16:17,560 --> 00:16:23,560
And on top of that, they need to secure their sensitive information.

205
00:16:23,560 --> 00:16:26,620
They can now use up to 40 V cores.

206
00:16:26,620 --> 00:16:31,240
So that is one improvement that we have done on the secure enclaves.

207
00:16:31,240 --> 00:16:34,520
Another improvement that we have made is another type of enclave.

208
00:16:34,520 --> 00:16:42,760
So next to the Intel SGX enclaves, we also now have virtualization based security or

209
00:16:42,760 --> 00:16:47,720
VBS enclaves that is general availability as of today.

210
00:16:47,720 --> 00:16:49,880
Like I said, it doesn't use any hardware.

211
00:16:49,880 --> 00:16:51,960
So there is no hardware dependency.

212
00:16:51,960 --> 00:16:59,240
You can use it in whatever database you configure, like DTU, V-Core, serverless.

213
00:16:59,240 --> 00:17:02,200
You can go up to 128 V cores.

214
00:17:02,200 --> 00:17:06,320
And it is also available in all the Azure regions.

215
00:17:06,320 --> 00:17:09,440
So these are the two improvements that we have done.

216
00:17:09,440 --> 00:17:11,800
The VBS enclaves, I think, is critically important.

217
00:17:11,800 --> 00:17:13,520
Actually, they're both really important.

218
00:17:13,520 --> 00:17:17,600
But the VBS one, I think, is important because you can basically choose any computer under

219
00:17:17,600 --> 00:17:18,600
the covers, right?

220
00:17:18,600 --> 00:17:26,400
You're not limited to essentially virtual machines under the covers that use specific

221
00:17:26,400 --> 00:17:30,320
Intel CPUs that have SGX enabled.

222
00:17:30,320 --> 00:17:31,320
So that's really cool.

223
00:17:31,320 --> 00:17:36,360
I think it's really important because it just gives more people so much more flexibility

224
00:17:36,360 --> 00:17:37,360
when it comes to compute.

225
00:17:37,360 --> 00:17:38,360
That's fantastic.

226
00:17:38,360 --> 00:17:39,360
Well, yeah.

227
00:17:39,360 --> 00:17:43,060
I was just going to say that it's very easy to enable a VBS enclave.

228
00:17:43,060 --> 00:17:49,120
So it's just a switch in the portal, or you can use PowerShell or even in the SQL Server

229
00:17:49,120 --> 00:17:50,720
Management Studio.

230
00:17:50,720 --> 00:17:55,680
You now have the option to just, yeah, on creation or even for an existing database.

231
00:17:55,680 --> 00:17:58,320
You can easily switch on VBS enclaves.

232
00:17:58,320 --> 00:18:02,080
Just takes a couple of seconds to load the enclave, and then we're good to go.

233
00:18:02,080 --> 00:18:04,080
And yeah, you can start using always encrypted.

234
00:18:04,080 --> 00:18:05,080
Yeah.

235
00:18:05,080 --> 00:18:06,080
I think that's important as well, right?

236
00:18:06,080 --> 00:18:10,480
Because if you want to deploy this thing, you want it to be relatively straightforward,

237
00:18:10,480 --> 00:18:11,480
right?

238
00:18:11,480 --> 00:18:12,480
Not ridiculously complex.

239
00:18:12,480 --> 00:18:13,480
Exactly.

240
00:18:13,480 --> 00:18:14,480
All right.

241
00:18:14,480 --> 00:18:16,480
So let's bring this to a close.

242
00:18:16,480 --> 00:18:18,480
Mirricompeter, thanks so much for joining us this week.

243
00:18:18,480 --> 00:18:23,760
I just want to kind of wrap things up with just from my perspective, because I certainly

244
00:18:23,760 --> 00:18:24,760
talk to customers.

245
00:18:24,760 --> 00:18:27,240
Yeah, so TDE, always encrypted.

246
00:18:27,240 --> 00:18:28,240
Which do I use when?

247
00:18:28,240 --> 00:18:31,000
I mean, why do you have these two solutions?

248
00:18:31,000 --> 00:18:32,000
It's really important.

249
00:18:32,000 --> 00:18:35,280
Whenever you look at any security defense, any kind of mitigation, any security control,

250
00:18:35,280 --> 00:18:39,000
you always think about what threat are you mitigating?

251
00:18:39,000 --> 00:18:43,080
And TDE and always encrypted, even though there is some overlap, they do mitigate different

252
00:18:43,080 --> 00:18:44,740
threats.

253
00:18:44,740 --> 00:18:47,160
And also they come with some ease of use trade-offs as well.

254
00:18:47,160 --> 00:18:53,080
So for example, TDE is really designed to mitigate a stolen hard drive or a stolen volume.

255
00:18:53,080 --> 00:18:55,360
This becomes really important with backups.

256
00:18:55,360 --> 00:19:00,720
As Merrick said before, the backup is always encrypted with the same key hierarchy, or

257
00:19:00,720 --> 00:19:02,960
uses the same key hierarchy, I should say.

258
00:19:02,960 --> 00:19:09,520
So if a backup is stored elsewhere, then it is encrypted.

259
00:19:09,520 --> 00:19:13,080
And it's a very important defense for the likes of backups, not just for the volume

260
00:19:13,080 --> 00:19:15,240
itself, but also for the backups.

261
00:19:15,240 --> 00:19:21,120
Whereas always encrypted is designed to not just provide a solution for encryption of

262
00:19:21,120 --> 00:19:26,340
data at rest, it also provides a solution for encryption of data in use.

263
00:19:26,340 --> 00:19:32,700
And as Peter mentioned, the data is essentially always encrypted, hence the name.

264
00:19:32,700 --> 00:19:37,760
The only time it's not encrypted is inside the secure enclave, which is a cordoned off

265
00:19:37,760 --> 00:19:38,760
portion of memory.

266
00:19:38,760 --> 00:19:43,200
I'm not going to go into all the technicalities of that, because that would be up here all

267
00:19:43,200 --> 00:19:44,200
day.

268
00:19:44,200 --> 00:19:46,560
But essentially it's completely cordoned off.

269
00:19:46,560 --> 00:19:50,400
Debuggers don't even see that they're there, that the memory is even there.

270
00:19:50,400 --> 00:19:52,220
So you can't actually peer inside it.

271
00:19:52,220 --> 00:19:56,840
And that's the only point where the data is decrypted, and that's where the queries are

272
00:19:56,840 --> 00:19:59,000
performed and so on.

273
00:19:59,000 --> 00:20:03,120
So they are similar on the surface, but they're actually quite different.

274
00:20:03,120 --> 00:20:06,200
And certainly the technologies are very different under the covers as well.

275
00:20:06,200 --> 00:20:12,280
So when you're thinking about what it takes to design a secure Azure SQL database solution,

276
00:20:12,280 --> 00:20:15,120
you really need to think about both, because they do mitigate different threats.

277
00:20:15,120 --> 00:20:17,320
They're not the same technology at all.

278
00:20:17,320 --> 00:20:20,400
So with that, Peter and Merrick, thank you so much for joining me this week.

279
00:20:20,400 --> 00:20:22,400
I really appreciate you taking the time.

280
00:20:22,400 --> 00:20:28,000
I think these are fantastic improvements, both across TDE and always encrypted.

281
00:20:28,000 --> 00:20:32,960
Kind of answering our customers' pain points is always good to see.

282
00:20:32,960 --> 00:20:34,680
So again, thank you so much for joining us.

283
00:20:34,680 --> 00:20:36,960
And to all our listeners out there, thank you to you as well.

284
00:20:36,960 --> 00:20:38,960
We hope you found this podcast useful.

285
00:20:38,960 --> 00:20:40,600
Stay safe and we'll see you next time.

286
00:20:40,600 --> 00:20:43,560
Thanks for listening to the Azure Security Podcast.

287
00:20:43,560 --> 00:20:50,400
You can find show notes and other resources at our website azsecuritypodcast.net.

288
00:20:50,400 --> 00:20:55,240
If you have any questions, please find us on Twitter at Azure Setpod.

289
00:20:55,240 --> 00:21:00,560
Background music is from ccmixtor.com and licensed under the Creative Commons license.