1 00:00:00,000 --> 00:00:09,600 Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, 2 00:00:09,600 --> 00:00:13,280 reliability, and compliance on the Microsoft Cloud Platform. 3 00:00:13,280 --> 00:00:15,720 Hey, everybody. 4 00:00:15,720 --> 00:00:16,720 Welcome to Episode 71. 5 00:00:16,720 --> 00:00:19,120 This is going to be one of those special episodes. 6 00:00:19,120 --> 00:00:24,780 I'm here with my colleague, Peter Van Hover, to talk about a feature that is about to go 7 00:00:24,780 --> 00:00:31,920 into preview, which is Azure SQL Database using, always encrypted, using virtualization-based 8 00:00:31,920 --> 00:00:32,920 security. 9 00:00:32,920 --> 00:00:33,920 This is actually a really cool feature. 10 00:00:33,920 --> 00:00:36,760 Again, we're going to talk about this in more detail with Peter. 11 00:00:36,760 --> 00:00:40,240 But before we get stuck into it, Peter, welcome to the podcast. 12 00:00:40,240 --> 00:00:43,160 We'd like to take a moment and just introduce yourself to our listeners. 13 00:00:43,160 --> 00:00:44,160 Yeah. 14 00:00:44,160 --> 00:00:45,160 Hi, Michael. 15 00:00:45,160 --> 00:00:46,160 Thanks for having me. 16 00:00:46,160 --> 00:00:47,960 So, yeah, I'm Peter. 17 00:00:47,960 --> 00:00:52,600 I'm a program manager in the data platform security team. 18 00:00:52,600 --> 00:00:58,440 That's the team that manages all the security features in Azure SQL, in managed instance, 19 00:00:58,440 --> 00:01:04,080 in SQL Server, but also all the other data platform services that we have, like Cosmos 20 00:01:04,080 --> 00:01:06,920 DB, Postgres SQL, and MySQL. 21 00:01:06,920 --> 00:01:14,260 And I'm the program manager for two features, for Ledger, which is all about data integrity. 22 00:01:14,260 --> 00:01:17,800 And I'm also the program manager for always encrypted. 23 00:01:17,800 --> 00:01:18,800 Very cool. 24 00:01:18,800 --> 00:01:21,000 So for those who are not aware, so Peter and I are actually colleagues. 25 00:01:21,000 --> 00:01:22,000 We're on the same team. 26 00:01:22,000 --> 00:01:27,680 Peter looks after, as he mentioned, specific security features, whereas I'm more on the 27 00:01:27,680 --> 00:01:33,080 sort of engineering side of things, sort of looking at software design and threat modeling 28 00:01:33,080 --> 00:01:36,440 and code quality and crypto design and all that sort of stuff. 29 00:01:36,440 --> 00:01:40,840 So our paths cross on a very regular basis. 30 00:01:40,840 --> 00:01:41,840 So this is actually really cool stuff. 31 00:01:41,840 --> 00:01:48,800 And it's a new feature that is, again, in preview for Azure SQL DB, always encrypted, 32 00:01:48,800 --> 00:01:54,600 using a new form of enclave technology called virtualization based security or VBS. 33 00:01:54,600 --> 00:01:58,280 So before we get stuck into that, we position this new technology, Peter, why don't we just 34 00:01:58,280 --> 00:02:04,740 go through the current options that we have today in both SQL Server on-prem or in a VM, 35 00:02:04,740 --> 00:02:07,100 as well as Azure SQL DB. 36 00:02:07,100 --> 00:02:11,200 So if you want to sort of rattle off those options and then we'll discuss them and then 37 00:02:11,200 --> 00:02:14,200 hopefully we'll lead into always encrypted. 38 00:02:14,200 --> 00:02:20,440 First option that our customers have in SQL and in Azure SQL is TDE or Transparent Data 39 00:02:20,440 --> 00:02:22,000 Encryption. 40 00:02:22,000 --> 00:02:25,840 And like I mentioned, it is completely transparent for our customers. 41 00:02:25,840 --> 00:02:30,680 So what is the engine doing is it's really encryption at rest. 42 00:02:30,680 --> 00:02:35,680 So everything that is written to the data files or written to disk before it is written 43 00:02:35,680 --> 00:02:38,720 to the disk, it is going to be encrypted. 44 00:02:38,720 --> 00:02:44,080 And if you need to read something from disk, we're going to fetch it from the data files 45 00:02:44,080 --> 00:02:49,300 you're going to decrypt it and load it decrypted in the memory of SQL Server. 46 00:02:49,300 --> 00:02:55,280 So for the customers, for the applications, it's completely transparent. 47 00:02:55,280 --> 00:03:01,560 And like I said, it's really encryption at rest, so not in use. 48 00:03:01,560 --> 00:03:06,680 Another technology that we have is column encryption, which is a technology where you 49 00:03:06,680 --> 00:03:13,440 can encrypt specific columns using a certificate and symmetric keys as well, kind of like an 50 00:03:13,440 --> 00:03:16,960 older technology, I think, to be honest. 51 00:03:16,960 --> 00:03:24,640 Then in Azure, we also have SQL that can run in a confidential virtual machine, which basically 52 00:03:24,640 --> 00:03:30,760 it's a specific machine that is using specific hardware as well under the hood so that you 53 00:03:30,760 --> 00:03:38,600 can have it's a specific CPU that is used under the hood, which means that the VM memory 54 00:03:38,600 --> 00:03:45,400 is completely encrypted and the integrity is protected by the CPU that has created the 55 00:03:45,400 --> 00:03:46,400 keys for that. 56 00:03:46,400 --> 00:03:54,120 Yeah, it's an AMD EPIC CPU or virtual CPU using a technology called SEV-SMP. 57 00:03:54,120 --> 00:03:56,120 It's actually pretty cool technology. 58 00:03:56,120 --> 00:03:59,320 I see Intel just released something very similar as well and we're looking at that. 59 00:03:59,320 --> 00:04:02,920 I shall put a link to that in the show notes as well, just out of interest. 60 00:04:02,920 --> 00:04:08,240 But yeah, so the keys, the actual symmetric keys that are used to encrypt the VM in use 61 00:04:08,240 --> 00:04:12,440 while it's actually being in use of the memory and everything, they're ephemeral keys that 62 00:04:12,440 --> 00:04:14,280 are actually managed by the CPU. 63 00:04:14,280 --> 00:04:15,280 So it's actually pretty cool stuff. 64 00:04:15,280 --> 00:04:19,640 There's obviously a performance implication of that, but by the same token, it's very 65 00:04:19,640 --> 00:04:22,080 good for very, very simple lift and shift stuff. 66 00:04:22,080 --> 00:04:23,260 Yeah, it's cool stuff. 67 00:04:23,260 --> 00:04:29,720 If you look at these three technologies that we just mentioned, none of these protects 68 00:04:29,720 --> 00:04:33,380 your data from, for example, malicious DBAs. 69 00:04:33,380 --> 00:04:38,940 If you look at TDE, it is decrypted when it is loaded into memory, so everybody that has 70 00:04:38,940 --> 00:04:42,120 access to your database can clearly read the data. 71 00:04:42,120 --> 00:04:44,080 So we created a new technology. 72 00:04:44,080 --> 00:04:47,560 Well, it's not that new anymore, which is called Always Encrypted. 73 00:04:47,560 --> 00:04:54,440 So if you look at the motivation to create Always Encrypted was to protect your data 74 00:04:54,440 --> 00:05:00,280 from malicious DBAs or people that cannot see your data. 75 00:05:00,280 --> 00:05:05,280 To give you an example, in my previous life, I was a DBA and when I came to customers, 76 00:05:05,280 --> 00:05:10,880 I always had full access to their databases, so I could just literally see everything. 77 00:05:10,880 --> 00:05:16,480 And sometimes, of course, if you have very sensitive information, an external person 78 00:05:16,480 --> 00:05:21,960 like me as a consultant, I shouldn't have access to or I shouldn't be able to read this 79 00:05:21,960 --> 00:05:23,080 data. 80 00:05:23,080 --> 00:05:30,820 So that was one of the motivations to start creating Always Encrypted to enable our customers 81 00:05:30,820 --> 00:05:36,120 to confidentially store the most sensitive data in the cloud. 82 00:05:36,120 --> 00:05:41,880 So we started with Always Encrypted with our journey in 2015. 83 00:05:41,880 --> 00:05:46,920 So as I said, the feature is not that new anymore with an initial version of Always 84 00:05:46,920 --> 00:05:47,920 Encrypted. 85 00:05:47,920 --> 00:05:54,720 So it's really a client-side encryption technology, so the data gets completely encrypted on the 86 00:05:54,720 --> 00:06:00,340 client sites within the client driver there and before it is being stored in the database. 87 00:06:00,340 --> 00:06:07,600 So we consider only the application site as a trusted part and the network and database 88 00:06:07,600 --> 00:06:10,400 engine is considered as non-trusted. 89 00:06:10,400 --> 00:06:16,320 So it means that the data is never decrypted inside the database, which means it provides 90 00:06:16,320 --> 00:06:19,640 you strong encryption. 91 00:06:19,640 --> 00:06:25,240 But on the other hand, it gives you quite some limitations if you look at the computation 92 00:06:25,240 --> 00:06:28,760 of this protected data or these encrypted columns. 93 00:06:28,760 --> 00:06:34,000 And one of the limitations, for example, with Always Encrypted was that you could only use 94 00:06:34,000 --> 00:06:37,640 equality comparison on encrypted columns. 95 00:06:37,640 --> 00:06:42,600 It even then had to support deterministic encryption. 96 00:06:42,600 --> 00:06:47,600 Do you know, Michael, the difference between deterministic encryption and randomized encryption? 97 00:06:47,600 --> 00:06:50,120 Or should I also explain this a little bit further? 98 00:06:50,120 --> 00:06:51,720 Yeah, I can explain it. 99 00:06:51,720 --> 00:06:54,400 You know, as the sort of the resident crypto nerd. 100 00:06:54,400 --> 00:06:55,400 Yeah. 101 00:06:55,400 --> 00:06:56,400 Yeah. 102 00:06:56,400 --> 00:06:59,520 So Always Encrypted supports two ways of encrypting a column of data. 103 00:06:59,520 --> 00:07:01,920 So the data can be encrypted. 104 00:07:01,920 --> 00:07:05,360 By the way, it's always using the same key. 105 00:07:05,360 --> 00:07:10,240 The key is randomized for different tables, but it's the same key. 106 00:07:10,240 --> 00:07:16,640 If you use deterministic, then for those of you who know about crypto, for a symmetric 107 00:07:16,640 --> 00:07:19,200 block cipher, you have to have an initialization beta. 108 00:07:19,200 --> 00:07:24,480 And the reason why an IV exists is so that if you encrypt two plaintexts that are the 109 00:07:24,480 --> 00:07:28,400 same, if you have a different IV, you get different ciphertexts, even though the key 110 00:07:28,400 --> 00:07:30,600 is the same. 111 00:07:30,600 --> 00:07:33,680 So for deterministic encryption, we actually have the same. 112 00:07:33,680 --> 00:07:36,140 The IV is actually the plaintext. 113 00:07:36,140 --> 00:07:40,720 So if you have two plaintexts, it's always the same IV. 114 00:07:40,720 --> 00:07:46,200 With randomized, you have a unique IV, a unique initialization vector, even though the key 115 00:07:46,200 --> 00:07:47,440 is the same. 116 00:07:47,440 --> 00:07:53,160 And that means that there is the resulting encryption operation results in different 117 00:07:53,160 --> 00:07:54,160 ciphertext. 118 00:07:54,160 --> 00:08:00,840 So same key, different IV, same plaintext will actually give you different ciphertext. 119 00:08:00,840 --> 00:08:03,080 So that's the difference between the two of them. 120 00:08:03,080 --> 00:08:11,240 The nice thing about deterministic is that it can be queried easily without using a secure 121 00:08:11,240 --> 00:08:12,240 enclave. 122 00:08:12,240 --> 00:08:14,840 But that's a discussion we're going to get into in a minute. 123 00:08:14,840 --> 00:08:19,000 So do you think that's probably enough I need to talk about with the difference between 124 00:08:19,000 --> 00:08:20,000 the two? 125 00:08:20,000 --> 00:08:21,000 Yeah, sure. 126 00:08:21,000 --> 00:08:22,200 No problem. 127 00:08:22,200 --> 00:08:29,080 So this first version of Always Encrypted was released in SQL 2016, and it is still 128 00:08:29,080 --> 00:08:30,080 available. 129 00:08:30,080 --> 00:08:36,120 If you look at the next versions, you can still use Always Encrypted like it was before. 130 00:08:36,120 --> 00:08:41,120 It is also available in Azure SQL DB, in Managed Instance, and also in Cosmos DB. 131 00:08:41,120 --> 00:08:47,880 So we released Always Encrypted last year in Cosmos DB because there was also a demand 132 00:08:47,880 --> 00:08:50,200 to have it in there as well. 133 00:08:50,200 --> 00:08:57,760 So next, what we've done then is we wanted to expand the capabilities of Always Encrypted 134 00:08:57,760 --> 00:09:01,760 because you didn't have much flexibility there. 135 00:09:01,760 --> 00:09:06,720 And we introduced a new technology like everybody mentioned, Michael, which is called secure 136 00:09:06,720 --> 00:09:09,280 enclaves. 137 00:09:09,280 --> 00:09:11,120 And what does it mean? 138 00:09:11,120 --> 00:09:17,220 Well, when processing SQL queries, the database engine delegates computations on encrypted 139 00:09:17,220 --> 00:09:19,360 data to that secure enclave. 140 00:09:19,360 --> 00:09:30,600 So it is kind of like an isolated region of memory, and all the data that is stored inside 141 00:09:30,600 --> 00:09:38,600 that enclave cannot be accessed from outside the enclave, meaning cannot be accessed from 142 00:09:38,600 --> 00:09:42,080 the OS, from OS administrators, from DBA. 143 00:09:42,080 --> 00:09:46,240 So it's really, really a secure environment. 144 00:09:46,240 --> 00:09:52,720 So it means that the enclave then decrypts the data and then can perform these computations 145 00:09:52,720 --> 00:09:54,000 on plaintext. 146 00:09:54,000 --> 00:10:01,140 So like I said, it's done completely safe because the enclave is a black box due to 147 00:10:01,140 --> 00:10:04,280 containing database engine process and the OS. 148 00:10:04,280 --> 00:10:10,680 So not even DBAs or machine administrators or whatever, they can look inside that enclave. 149 00:10:10,680 --> 00:10:12,260 So this is incredibly important. 150 00:10:12,260 --> 00:10:14,800 This is really the whole linchpin of the whole thing, right? 151 00:10:14,800 --> 00:10:19,480 If the enclave, the SGX enclave, so SGX stands for Software Guard Extensions. 152 00:10:19,480 --> 00:10:22,200 It's an Intel technology. 153 00:10:22,200 --> 00:10:27,520 So the root of trust for that goes all the way down to the CPU or the virtual CPU. 154 00:10:27,520 --> 00:10:32,040 And that memory is completely isolated and is encrypted in use. 155 00:10:32,040 --> 00:10:37,120 So the actual symmetric keys that are used to encrypt that SGX, that SGX enclave, I should 156 00:10:37,120 --> 00:10:40,400 say, are actually managed by the CPU. 157 00:10:40,400 --> 00:10:41,400 They're not managed by Azure. 158 00:10:41,400 --> 00:10:43,960 They're not managed by the tenant. 159 00:10:43,960 --> 00:10:46,440 They're managed completely by the CPU. 160 00:10:46,440 --> 00:10:50,400 So it's actually really cool because that way it restricts who has access. 161 00:10:50,400 --> 00:10:54,840 And again, like you mentioned, malicious VBA does not have access to the CPU and they certainly 162 00:10:54,840 --> 00:10:59,400 do not have access to the internal hardware of the CPU to access the symmetric keys. 163 00:10:59,400 --> 00:11:03,760 So it's a very strong defense, incredibly strong defense. 164 00:11:03,760 --> 00:11:10,680 And on top of that, when you use secure enclaves, it is now possible or we can now support rich 165 00:11:10,680 --> 00:11:20,360 confidential queries, which means you can use pattern matching like range queries or 166 00:11:20,360 --> 00:11:23,920 range comparisons like larger than, smaller than. 167 00:11:23,920 --> 00:11:26,160 You can sort on encrypted columns. 168 00:11:26,160 --> 00:11:28,600 You can put an index on it. 169 00:11:28,600 --> 00:11:30,520 You can group by, you can order by. 170 00:11:30,520 --> 00:11:36,120 So these are all extra, not functionalities, but yeah, you get this. 171 00:11:36,120 --> 00:11:40,480 This is now all possible by using these secure enclaves. 172 00:11:40,480 --> 00:11:43,920 And you can also use in-place encryption. 173 00:11:43,920 --> 00:11:50,920 It means that, for example, you can start or you can encrypt existing data without moving 174 00:11:50,920 --> 00:11:55,360 the data out of the database, which was, or which is not possible with the first version 175 00:11:55,360 --> 00:11:59,960 of always encrypted, which is now possible with using the enclaves as well. 176 00:11:59,960 --> 00:12:01,360 Yeah, I forgot about that. 177 00:12:01,360 --> 00:12:02,360 That's actually pretty cool. 178 00:12:02,360 --> 00:12:05,020 And actually there's another thing that a lot of people don't realize exists. 179 00:12:05,020 --> 00:12:08,680 You can do this through SSMS, through SQL Server Management Studio or from PowerShell 180 00:12:08,680 --> 00:12:09,680 scripts. 181 00:12:09,680 --> 00:12:14,720 So when using always encrypted with secure enclaves, you can actually also do data encryption 182 00:12:14,720 --> 00:12:17,680 key rotation, not just key encryption, key rotation. 183 00:12:17,680 --> 00:12:21,600 I mean, data encryption, key rotation while the database is, well, while the table is 184 00:12:21,600 --> 00:12:24,600 still being used. 185 00:12:24,600 --> 00:12:29,840 And you can sort of set up some parameters to say, hey, rotate 3% of the database at 186 00:12:29,840 --> 00:12:32,760 a time or the table at a time. 187 00:12:32,760 --> 00:12:37,760 And it will try to not sort of impinge on the business processes. 188 00:12:37,760 --> 00:12:42,360 So being able to actually rotate data encryption keys while the database is in use is actually 189 00:12:42,360 --> 00:12:43,360 really, really cool. 190 00:12:43,360 --> 00:12:48,560 Yes, that's another real nice benefit that always encrypted brings to the table. 191 00:12:48,560 --> 00:12:50,440 Yes, exactly. 192 00:12:50,440 --> 00:12:57,200 This version of always encrypted with secure enclaves was released in SQL Server 2019 and 193 00:12:57,200 --> 00:13:03,280 improved in SQL 2022 and is also available in Azure SQL Database. 194 00:13:03,280 --> 00:13:09,140 Now if we look at Azure SQL Database, if you want to use secure enclaves, you have to configure 195 00:13:09,140 --> 00:13:12,360 a specific hardware configuration. 196 00:13:12,360 --> 00:13:18,040 Like you said, Michael, you need to have or we're using an Intel Software Guard extension 197 00:13:18,040 --> 00:13:22,760 or SGX that is managing the enclave. 198 00:13:22,760 --> 00:13:27,840 And if you want to use that, you have to configure what we call a DC series in Azure. 199 00:13:27,840 --> 00:13:33,260 So when you configure your database, you have to select this specific DC series, which under 200 00:13:33,260 --> 00:13:39,080 the hood is going to use that specific Intel CPU. 201 00:13:39,080 --> 00:13:46,320 Now we have a lot of customers that are using these DC series, but it comes with some, let's 202 00:13:46,320 --> 00:13:48,020 say, consequences. 203 00:13:48,020 --> 00:13:50,920 Like you said, there's no free lunch, right? 204 00:13:50,920 --> 00:13:55,400 It means that if you want to use DC series, you're limited to the FECORE model. 205 00:13:55,400 --> 00:14:00,440 So you cannot use the DTUs if you would like to use that. 206 00:14:00,440 --> 00:14:05,040 On top of that, you always have to use the compute model provision. 207 00:14:05,040 --> 00:14:10,280 So serverless is not available with the DC series. 208 00:14:10,280 --> 00:14:15,760 And yeah, one of the limitations that we also have currently is that we're using, or the 209 00:14:15,760 --> 00:14:20,600 maximum number of physical FECOREs that you can use is eight. 210 00:14:20,600 --> 00:14:26,520 So if we have some customers, they're using always encrypted, so not always encrypted, 211 00:14:26,520 --> 00:14:31,880 secure enclaves, because they need to have more than eight FECOREs. 212 00:14:31,880 --> 00:14:36,240 And yeah, currently we do not have that functionality. 213 00:14:36,240 --> 00:14:43,240 So this is really a limitation in the DC series. 214 00:14:43,240 --> 00:14:49,040 Another topic that I want to point out is that in Azure for the moment, the DC series 215 00:14:49,040 --> 00:14:51,320 are not available in every region. 216 00:14:51,320 --> 00:14:55,100 So it's limited to a number of regions. 217 00:14:55,100 --> 00:15:01,160 So that's also one of the limitations that we have with SGX. 218 00:15:01,160 --> 00:15:02,600 But we're working on this. 219 00:15:02,600 --> 00:15:09,380 So we are making improvements on SGX as well for the moment. 220 00:15:09,380 --> 00:15:15,260 If we look at always encrypted enclaves in SQL Server 2019, the enclaves are there used 221 00:15:15,260 --> 00:15:21,560 by VBS enclaves or virtualization security, based security. 222 00:15:21,560 --> 00:15:22,560 Now what is VBS? 223 00:15:22,560 --> 00:15:29,800 VBS is a software based technology that relies on Windows hypervisor and does not require 224 00:15:29,800 --> 00:15:33,040 any specific hardware there. 225 00:15:33,040 --> 00:15:40,040 So that's currently what we support in SQL Server 2019 and SQL 2022. 226 00:15:40,040 --> 00:15:42,360 I think it's an important point, the VBS stuff, right? 227 00:15:42,360 --> 00:15:47,720 So we do have memory isolation, just as we do with SGX, but the isolation technology 228 00:15:47,720 --> 00:15:48,720 is different. 229 00:15:48,720 --> 00:15:53,160 So rather than being something that's done by the Intel CPU, this is something that's 230 00:15:53,160 --> 00:15:56,920 actually being done by a virtualization environment like hypervisor. 231 00:15:56,920 --> 00:16:01,080 So the same sort of isolation that you'd get between say VMs as an example, that same kind 232 00:16:01,080 --> 00:16:05,640 of technology is being used to isolate a smaller chunk of memory. 233 00:16:05,640 --> 00:16:10,640 And that smaller chunk of memory runs a part of the SQL Server query engine, but that memory 234 00:16:10,640 --> 00:16:14,920 is completely isolated from say the operating system that you're running on. 235 00:16:14,920 --> 00:16:21,200 So if you actually have a rogue on the machine, they can't actually get to the memory that's 236 00:16:21,200 --> 00:16:23,560 inside of this VBS enclave. 237 00:16:23,560 --> 00:16:27,240 And again, that's all enforced by the hypervisor. 238 00:16:27,240 --> 00:16:34,160 So now the whole purpose of this podcast is that we introduce a new flavor, let's call 239 00:16:34,160 --> 00:16:41,520 it, of always encrypted with secure enclaves in Azure SQL database, not using SGX enclaves, 240 00:16:41,520 --> 00:16:45,000 but using VBS enclaves. 241 00:16:45,000 --> 00:16:51,080 We're launching the public preview today of VBS enclaves in Azure SQL database, which 242 00:16:51,080 --> 00:16:59,400 means it gives our customers a lot more advantages compared to SGX because as we mentioned, there 243 00:16:59,400 --> 00:17:06,100 is no hardware dependency, which means that our customers, they can configure whatever 244 00:17:06,100 --> 00:17:09,960 database they want and they can use always encrypted with secure enclaves. 245 00:17:09,960 --> 00:17:14,320 So they can choose to go for DTU or still go for VCores. 246 00:17:14,320 --> 00:17:18,580 They can go for a compute model provisioned or even serverless. 247 00:17:18,580 --> 00:17:21,720 Always encrypted functionality will work. 248 00:17:21,720 --> 00:17:25,720 The limitation of the number of VCores, we also don't have it. 249 00:17:25,720 --> 00:17:30,040 So you can specify as much VCores as you want. 250 00:17:30,040 --> 00:17:36,680 And currently I think the maximum is up to 128 VCores. 251 00:17:36,680 --> 00:17:41,440 And that is, yeah, so the limitation of the VCores also goes away. 252 00:17:41,440 --> 00:17:48,960 And this feature or VBS enclaves is available in all Azure regions. 253 00:17:48,960 --> 00:17:53,720 So there's no limitations anymore for the regions. 254 00:17:53,720 --> 00:17:56,400 And it's much easier to set up as well for our customers. 255 00:17:56,400 --> 00:17:59,040 So we're going in public preview with that today. 256 00:17:59,040 --> 00:18:00,520 So I think this is important, right? 257 00:18:00,520 --> 00:18:05,920 So SGX, very powerful, but it's more complex to set up. 258 00:18:05,920 --> 00:18:06,920 It doesn't scale as well. 259 00:18:06,920 --> 00:18:10,440 It's not available in every region, but it's good at what it does. 260 00:18:10,440 --> 00:18:16,000 And then we have VBS, as you mentioned, which is now in preview, which offers a similar 261 00:18:16,000 --> 00:18:17,000 kind of mitigation. 262 00:18:17,000 --> 00:18:20,720 I mean, the implementation is different. 263 00:18:20,720 --> 00:18:23,760 But the key thing is, and I think this is so, so, so important because it's been like 264 00:18:23,760 --> 00:18:28,720 a very, very important pain point for customers, is the VMs. 265 00:18:28,720 --> 00:18:36,960 The underlying VMs that run the platform as a service as a SQL database is we had to use 266 00:18:36,960 --> 00:18:41,720 VMs that used the Intel CPU, the specific Intel CPU. 267 00:18:41,720 --> 00:18:48,480 And the problem with that is that, again, there are memory limitations, there were virtual 268 00:18:48,480 --> 00:18:50,760 CPU limitations and so on. 269 00:18:50,760 --> 00:18:56,360 And so we're sort of busting that wide open to allow you to use VBS enclaves, which don't 270 00:18:56,360 --> 00:18:57,360 have those limitations. 271 00:18:57,360 --> 00:18:59,160 Yeah. 272 00:18:59,160 --> 00:19:04,640 And Michael, one thing we forgot to mention is the cost. 273 00:19:04,640 --> 00:19:08,640 If you configure a DC series, it's quite expensive as well. 274 00:19:08,640 --> 00:19:15,320 So if our customers can go for VBS enclaves, they can reduce the costs as well, because 275 00:19:15,320 --> 00:19:18,400 you just pay the price of a normal database. 276 00:19:18,400 --> 00:19:25,100 So we don't charge any extra costs for always, or using always encrypted with secure enclaves. 277 00:19:25,100 --> 00:19:26,100 This is really cool stuff. 278 00:19:26,100 --> 00:19:31,600 I'm going to be honest, when I saw this was coming out, I got really excited because I 279 00:19:31,600 --> 00:19:38,040 think it's still going to offer many of the benefits of the SGX enclaves, but without 280 00:19:38,040 --> 00:19:45,600 the complexity, without the cost, more scalability, and more region support, which is great to 281 00:19:45,600 --> 00:19:46,600 see. 282 00:19:46,600 --> 00:19:50,520 So this is a really good example of the family of always encrypted, sort of growing. 283 00:19:50,520 --> 00:19:53,940 We have it in SQL Server on-prem, which uses VBS. 284 00:19:53,940 --> 00:19:57,600 We have Azure SQL Database, for example, in the cloud using SGX. 285 00:19:57,600 --> 00:20:02,680 And now we have Azure SQL Database in the cloud using VBS as well. 286 00:20:02,680 --> 00:20:04,760 So it really is a pretty broad family. 287 00:20:04,760 --> 00:20:09,280 So you can sort of choose what you need in terms of cost and performance and security, 288 00:20:09,280 --> 00:20:10,880 which is great to see. 289 00:20:10,880 --> 00:20:11,880 Yeah. 290 00:20:11,880 --> 00:20:13,360 The always encrypted family is growing. 291 00:20:13,360 --> 00:20:15,360 That's for sure. 292 00:20:15,360 --> 00:20:18,120 My background is obviously application development. 293 00:20:18,120 --> 00:20:22,160 And I've worked with a couple of customers over the years who have looked at always encrypted. 294 00:20:22,160 --> 00:20:27,160 It's an interesting issue because, look, I'm going to be honest, I think it's a very difficult 295 00:20:27,160 --> 00:20:35,480 proposition to take an existing system beyond a hello world environment, take an existing 296 00:20:35,480 --> 00:20:39,600 say Azure SQL Database environment and just sort of flip the always encrypted bit. 297 00:20:39,600 --> 00:20:44,000 It's not as simple as that, but anyway, flip the always encrypted bit and expect the application 298 00:20:44,000 --> 00:20:45,000 to work. 299 00:20:45,000 --> 00:20:49,360 It's probably not because certain queries may not work. 300 00:20:49,360 --> 00:20:54,120 Even VBS or SGX enclaves don't support the entire SQL syntax. 301 00:20:54,120 --> 00:20:58,920 They certainly are a much bigger syntax than just equality and inequality, which is what 302 00:20:58,920 --> 00:21:02,560 the always encrypted with no enclaves supports. 303 00:21:02,560 --> 00:21:06,840 So my own personal recommendation is sure, you have an existing system, look at what 304 00:21:06,840 --> 00:21:09,960 it might take to migrate to always encrypted. 305 00:21:09,960 --> 00:21:13,760 But I think the sweet spot, and correct me if I'm wrong here, but I think the sweet spot 306 00:21:13,760 --> 00:21:15,960 is going to be something new, something green field. 307 00:21:15,960 --> 00:21:18,600 In other words, you're designing something from the get go. 308 00:21:18,600 --> 00:21:20,760 So let's design it with always encrypted in mind. 309 00:21:20,760 --> 00:21:21,760 Is that a fair comment? 310 00:21:21,760 --> 00:21:22,760 Yeah, for sure. 311 00:21:22,760 --> 00:21:23,760 Yeah, definitely. 312 00:21:23,760 --> 00:21:27,480 It's not that easy to like you're right. 313 00:21:27,480 --> 00:21:32,320 It's not that easy to convert an existing application and yeah, immediately start using 314 00:21:32,320 --> 00:21:33,320 always encrypted. 315 00:21:33,320 --> 00:21:36,240 No, it is a complex topic. 316 00:21:36,240 --> 00:21:39,000 But that being said, if you are designing something from the get go and you have some 317 00:21:39,000 --> 00:21:43,880 columns, for example, social security numbers is a great example in the US, right? 318 00:21:43,880 --> 00:21:48,400 Or sensitive medical information, that kind of stuff. 319 00:21:48,400 --> 00:21:52,080 Those are candidates for always encrypted columns. 320 00:21:52,080 --> 00:21:56,760 And if you design something from the get go and make sure that your developers understand 321 00:21:56,760 --> 00:22:00,680 the implications of always encrypted, the benefits are huge. 322 00:22:00,680 --> 00:22:03,600 The benefits from an attack perspective are huge. 323 00:22:03,600 --> 00:22:07,840 Because if you take, for example, column encryption, as you mentioned before, column encryption 324 00:22:07,840 --> 00:22:12,920 and TDE, if an attacker gets onto the SQL server or into the SQL server through whatever, 325 00:22:12,920 --> 00:22:15,760 they get plain text. 326 00:22:15,760 --> 00:22:19,960 Whereas if you compromise a system running always encrypted, the attacker gets cipher 327 00:22:19,960 --> 00:22:20,960 text. 328 00:22:20,960 --> 00:22:25,840 And that's an incredible story, right? 329 00:22:25,840 --> 00:22:34,480 Because no matter how hard, even if the attacker is a rogue, say SQL server admin, they don't 330 00:22:34,480 --> 00:22:38,520 have the plain text because they don't have access to the keys. 331 00:22:38,520 --> 00:22:43,040 And the keys are not held in memory like they are, say, for example, with column encryption. 332 00:22:43,040 --> 00:22:47,640 So even if an attacker could actually get into the memory space of SQL server, they 333 00:22:47,640 --> 00:22:51,240 can't get the data because the keys aren't there. 334 00:22:51,240 --> 00:22:57,040 In the case of SGX and VBS, the keys are held somewhere else where the attacker has no access 335 00:22:57,040 --> 00:23:02,160 because of either virtualization, in the case of VBS, or a secure enclave using SGX, in 336 00:23:02,160 --> 00:23:04,800 the case of, funny enough, SGX. 337 00:23:04,800 --> 00:23:08,840 So it's an incredible defense, but you have to design around it correctly. 338 00:23:08,840 --> 00:23:15,160 Yeah, looking at my example in the beginning of this podcast where I said I was a consultant, 339 00:23:15,160 --> 00:23:25,000 I went to financial companies like banks, insurance companies, they always gave me system 340 00:23:25,000 --> 00:23:28,140 administrator permissions on their SQL servers. 341 00:23:28,140 --> 00:23:33,320 So I literally could go in whatever table I wanted and if I wanted to, I could fetch 342 00:23:33,320 --> 00:23:35,680 all the data and go home with it. 343 00:23:35,680 --> 00:23:41,560 It was always encrypted to you, like you said, I didn't have the key so I couldn't see anything, 344 00:23:41,560 --> 00:23:43,640 but I could still do my job. 345 00:23:43,640 --> 00:23:49,040 I still have access to the databases, to the SQL servers, but I don't have access to the 346 00:23:49,040 --> 00:23:50,400 sensitive information. 347 00:23:50,400 --> 00:23:55,680 So there's clearly a distinction there between who owns the data and who doesn't own the 348 00:23:55,680 --> 00:23:59,200 data and cannot see it. 349 00:23:59,200 --> 00:24:00,200 You bring up an interesting point. 350 00:24:00,200 --> 00:24:05,600 I had a summer experience as well where customers wanted to make me admins of one kind or another. 351 00:24:05,600 --> 00:24:08,040 It's funny because my answer has always been the same. 352 00:24:08,040 --> 00:24:10,680 It's like, no, I don't want to be an admin. 353 00:24:10,680 --> 00:24:11,680 I just don't. 354 00:24:11,680 --> 00:24:13,120 It's plausible deniability, right? 355 00:24:13,120 --> 00:24:17,360 If something bad happens, it can't have been me because I wasn't an admin. 356 00:24:17,360 --> 00:24:20,360 So anyone who's listening there, if you're in a consulting capacity and your customer 357 00:24:20,360 --> 00:24:24,800 says, hey, just be an admin on your database or be an admin in Linux or be an admin in 358 00:24:24,800 --> 00:24:29,360 Windows, the answer really should be no. 359 00:24:29,360 --> 00:24:35,000 Get someone who actually works for the company to do that work rather than you. 360 00:24:35,000 --> 00:24:36,000 I would never recommend that. 361 00:24:36,000 --> 00:24:41,280 Actually, I want to just point something else out here that always encrypted doesn't fix 362 00:24:41,280 --> 00:24:43,320 that people should be aware of. 363 00:24:43,320 --> 00:24:44,960 So always encrypted is actually... 364 00:24:44,960 --> 00:24:48,040 Actually the encrypted part is actually kind of a bit of a misnomer because it really should 365 00:24:48,040 --> 00:24:49,040 be always protected. 366 00:24:49,040 --> 00:24:53,400 If I had my way, I would have called it always protected because it's actually encryption 367 00:24:53,400 --> 00:24:54,680 and an HMAC, right? 368 00:24:54,680 --> 00:24:58,840 So it actually verifies the integrity of the data to make sure that data has not been manipulated. 369 00:24:58,840 --> 00:25:03,640 But what's interesting, and this is why it's always really important when you're ever considering 370 00:25:03,640 --> 00:25:07,680 any kind of defense, what does it actually fix? 371 00:25:07,680 --> 00:25:12,160 So let's just take a hypothetical example where there's a table that's got all the list 372 00:25:12,160 --> 00:25:14,920 of salaries within Microsoft. 373 00:25:14,920 --> 00:25:16,640 I could actually lift... 374 00:25:16,640 --> 00:25:21,480 If I had access to the data, obviously enough privilege to access the data and change data 375 00:25:21,480 --> 00:25:28,320 and what have you, and let's say the salary column was encrypted with always encrypted, 376 00:25:28,320 --> 00:25:33,320 there's nothing actually preventing me in always encrypted from taking the cipher text 377 00:25:33,320 --> 00:25:40,760 out of Satya's, our CEO's, out of his row to taking the salary column out of his row 378 00:25:40,760 --> 00:25:47,720 or his record, taking that out as cipher text and actually pasting it into my salary column. 379 00:25:47,720 --> 00:25:53,000 Always encrypted does not mitigate that because the data itself has not been tampered with. 380 00:25:53,000 --> 00:25:56,720 The HMAC protects the actual, let's just call it the cell, the cell of data. 381 00:25:56,720 --> 00:26:02,040 So if I try to change that, it won't compute correctly, it won't decrypt correctly. 382 00:26:02,040 --> 00:26:07,000 But there's nothing stopping me actually lifting that cell out and pasting it into my cell. 383 00:26:07,000 --> 00:26:11,320 Assuming of course, access control aside, there's nothing stopping that at all. 384 00:26:11,320 --> 00:26:14,240 But that's where technologies like Ledger come in, right? 385 00:26:14,240 --> 00:26:16,240 Because Ledger prevents that. 386 00:26:16,240 --> 00:26:17,560 Exactly. 387 00:26:17,560 --> 00:26:20,640 So that's why it's always really important to understand what you're actually mitigating 388 00:26:20,640 --> 00:26:21,880 with these technologies. 389 00:26:21,880 --> 00:26:26,400 So for many customers, it may actually be a combination of always encrypted with Ledger. 390 00:26:26,400 --> 00:26:30,080 And the nice thing about Ledger is there's nothing required from an application perspective. 391 00:26:30,080 --> 00:26:33,320 It's all done by the database engine, which is absolutely beautiful. 392 00:26:33,320 --> 00:26:36,440 All right, Peter, this has been really, really useful. 393 00:26:36,440 --> 00:26:39,280 It's great to see VBS enclaves. 394 00:26:39,280 --> 00:26:44,840 It just expands the population of users or developers or admins that would actually want 395 00:26:44,840 --> 00:26:46,880 to use this technology. 396 00:26:46,880 --> 00:26:52,040 But one thing that we always ask all our guests is if you had one thought to leave our listeners 397 00:26:52,040 --> 00:26:53,440 with, what would it be? 398 00:26:53,440 --> 00:27:00,000 What would it be is that I would love that everybody starts, well, since it's VBS enclaves, 399 00:27:00,000 --> 00:27:04,680 this is in public preview, I would love that our customers start using it, start playing 400 00:27:04,680 --> 00:27:08,220 with it, doing POCs with it and give us feedback. 401 00:27:08,220 --> 00:27:16,080 Maybe we can still improve the feature or our customers, they notice that something 402 00:27:16,080 --> 00:27:19,280 can be added to the feature or something is not working correctly. 403 00:27:19,280 --> 00:27:25,520 Yeah, we'd love to get the feedback of our customers that are trying VBS enclaves. 404 00:27:25,520 --> 00:27:28,600 All right, Peter, hey, thank you so much for joining us this week. 405 00:27:28,600 --> 00:27:33,240 I know you've been really busy, especially with the release of VBS enclaves. 406 00:27:33,240 --> 00:27:34,440 So thanks for taking the time out. 407 00:27:34,440 --> 00:27:36,520 I sincerely appreciate it. 408 00:27:36,520 --> 00:27:39,120 And to all our listeners out there, we hope you found this useful. 409 00:27:39,120 --> 00:27:41,480 As Peter said, go get the tires on VBS enclaves. 410 00:27:41,480 --> 00:27:43,680 It's actually pretty cool technology. 411 00:27:43,680 --> 00:27:46,280 And with that, stay safe and we'll see you next time. 412 00:27:46,280 --> 00:27:49,280 Thanks for listening to the Azure Security Podcast. 413 00:27:49,280 --> 00:27:56,120 You can find show notes and other resources at our website, azsecuritypodcast.net. 414 00:27:56,120 --> 00:28:00,920 If you have any questions, please find us on Twitter at Azure Setpod. 415 00:28:00,920 --> 00:28:27,920 Background music is from ccmixtor.com and licensed under the Creative Commons license.