WEBVTT 00:00:03.720 --> 00:00:06.240 Welcome to the Azure Security Podcast, where 00:00:06.240 --> 00:00:08.779 we discuss topics relating to security, privacy, 00:00:09.039 --> 00:00:11.480 reliability, and compliance on the Microsoft 00:00:11.480 --> 00:00:15.679 Cloud Platform. Hey everybody, welcome to episode 00:00:15.679 --> 00:00:19.519 114. This week it's myself, Michael. Here by 00:00:19.519 --> 00:00:22.100 myself, the other guys are all busy. I also have 00:00:22.100 --> 00:00:24.179 two guests this week to talk about SQL Server 00:00:24.179 --> 00:00:27.800 2025 security updates. Peter Vanhover, who is 00:00:27.800 --> 00:00:31.059 a regular on this podcast. In fact, I think this 00:00:31.059 --> 00:00:34.460 is number three. and Pratim Dasgupta, again, 00:00:34.600 --> 00:00:37.079 both from the Azure Data team and the SQL Server 00:00:37.079 --> 00:00:39.679 team. But before we get to our guests, I want 00:00:39.679 --> 00:00:42.340 to take a little journey around the news. I have 00:00:42.340 --> 00:00:46.179 four little items to talk about. The first one 00:00:46.179 --> 00:00:49.320 is, in case you're not aware, Microsoft Build, 00:00:49.520 --> 00:00:52.899 just finished in Seattle, and both myself and 00:00:52.899 --> 00:00:56.700 Sarah were both presented. I presented on reflections 00:00:56.700 --> 00:00:59.700 on 25 years of writing secure code. That's the 00:00:59.700 --> 00:01:01.859 book. First of all, it's absolutely terrifying. 00:01:02.060 --> 00:01:04.120 It's been 25 years since the first edition of 00:01:04.120 --> 00:01:06.620 Writing Secure Code came out. Lots of stories. 00:01:06.700 --> 00:01:08.799 It was a lot of fun giving the presentation. 00:01:09.159 --> 00:01:11.159 I also talk about the story where I convinced 00:01:11.159 --> 00:01:13.239 Bill Gates to write the foreword for the second 00:01:13.239 --> 00:01:16.799 edition. Just lots of stories and also how things 00:01:16.799 --> 00:01:18.579 have progressed over the years, especially from 00:01:18.579 --> 00:01:20.420 a tooling and sort of knowledge perspective and 00:01:20.420 --> 00:01:22.879 how threats have evolved. The other one that 00:01:22.879 --> 00:01:27.140 Sarah did was with Pamela Fox, deploying an end 00:01:27.140 --> 00:01:30.239 -to -end secure AI application. It's a fun watch, 00:01:30.319 --> 00:01:32.579 if nothing else. You'll learn a lot from this. 00:01:33.200 --> 00:01:35.640 So again, I'll provide links to both of those 00:01:35.640 --> 00:01:37.719 presentations. There are plenty of other security 00:01:37.719 --> 00:01:40.480 presentations as well, but I just want to call 00:01:40.480 --> 00:01:42.060 out those too many because, you know, we're both 00:01:42.060 --> 00:01:44.439 on the podcast. The other one which really caught 00:01:44.439 --> 00:01:48.859 my eye is a blog post from Ravinda Gupta. It's 00:01:48.859 --> 00:01:51.859 called Demystifying Azure Private Link Benefits, 00:01:51.859 --> 00:01:55.930 Pitfalls, and Best Practices. Honestly, This 00:01:55.930 --> 00:01:58.370 is probably the best five minute read I've ever 00:01:58.370 --> 00:02:01.810 read on Azure Private Link. It gives a really 00:02:01.810 --> 00:02:05.849 concrete set of examples of the benefits, kind 00:02:05.849 --> 00:02:09.650 of how it works and why you should use it. One 00:02:09.650 --> 00:02:12.530 thing that we find in the red team is one of 00:02:12.530 --> 00:02:17.449 the major problems we see. is when a service 00:02:17.449 --> 00:02:19.409 actually has a very flat network. In other words, 00:02:19.430 --> 00:02:22.490 they don't isolate critical parts of their infrastructure 00:02:22.490 --> 00:02:24.669 from other parts of the infrastructure. And that 00:02:24.669 --> 00:02:26.650 makes it really easy for the red team to traverse 00:02:26.650 --> 00:02:29.349 across the network. So PrivateLink really helps. 00:02:29.409 --> 00:02:32.250 And many other security isolation techniques 00:02:32.250 --> 00:02:35.069 really help make life really hard for the red 00:02:35.069 --> 00:02:37.250 team and for attackers for that matter. So if 00:02:37.250 --> 00:02:38.729 you're not familiar with PrivateLink or it's 00:02:38.729 --> 00:02:41.110 still a bit of a mystery to you, then do go ahead 00:02:41.110 --> 00:02:44.009 and check out this blog post. The last news item. 00:02:44.599 --> 00:02:46.500 There's a blog post been written as a follow 00:02:46.500 --> 00:02:49.860 -up from Sarah's blog post, which is understanding 00:02:49.860 --> 00:02:53.099 and mitigating security risks in MCP implementations. 00:02:53.240 --> 00:02:56.219 There's a follow -up to that. Actually, it's 00:02:56.219 --> 00:02:57.979 not really a follow -up. It's another blog post, 00:02:58.080 --> 00:03:02.319 sort of concerns about MCP from a security standpoint. 00:03:03.120 --> 00:03:04.939 and what we're doing at Microsoft to help mitigate 00:03:04.939 --> 00:03:07.139 some of those issues. So again, if you're using 00:03:07.139 --> 00:03:10.060 MCP, which is the model context protocol used 00:03:10.060 --> 00:03:14.159 to build AI applications, we sort of link things 00:03:14.159 --> 00:03:17.020 together, then do go take a good look at this. 00:03:17.439 --> 00:03:19.639 All right, that's the news out of the way. So 00:03:19.639 --> 00:03:21.240 let's turn our attention to the guests. As I 00:03:21.240 --> 00:03:24.039 mentioned, this week we have two guests, Prateem 00:03:24.039 --> 00:03:26.719 and Peter. So gentlemen, why don't you go and 00:03:26.719 --> 00:03:29.479 just take a moment and introduce yourself to 00:03:29.479 --> 00:03:32.719 our listeners. Sure. Hello, everybody. I'm Pratim 00:03:32.719 --> 00:03:35.680 Dasgupta, and I'm the product manager working 00:03:35.680 --> 00:03:39.060 on identity and SQL authentication. Hi, everybody. 00:03:39.240 --> 00:03:43.699 Yes, I'm Peter. I'm also a PM product manager 00:03:43.699 --> 00:03:47.599 in the data platform security team, and I'm managing 00:03:47.599 --> 00:03:50.919 everything related to data encryption. So transparent 00:03:50.919 --> 00:03:54.259 data encryption, always encrypted, and also ledger, 00:03:54.319 --> 00:03:57.360 which is everything related to data integrity 00:03:57.360 --> 00:04:00.979 and not data encryption. All right. So actually, 00:04:01.020 --> 00:04:03.020 before we get stuck into the actual content. 00:04:03.099 --> 00:04:04.819 So first of all, Peter, since I think last time 00:04:04.819 --> 00:04:06.740 we spoke on the podcast, you got a promotion, 00:04:06.919 --> 00:04:10.120 right? Oh, yes, yes. I did. I did. Yeah. I'm 00:04:10.120 --> 00:04:12.259 a senior PM now. You're a senior PM. Fantastic. 00:04:12.500 --> 00:04:15.819 That's good. Good stuff, man. You know, you do 00:04:15.819 --> 00:04:18.600 good stuff, man. So, yeah, congratulations. Thanks. 00:04:19.439 --> 00:04:21.399 Let's get stuck into this. So we've got three 00:04:21.399 --> 00:04:24.899 broad categories, entry authentication, cryptographic 00:04:24.899 --> 00:04:26.899 updates, and then security cache improvements. 00:04:27.420 --> 00:04:30.540 So why don't we start with Prateem, and if you 00:04:30.540 --> 00:04:32.899 want to go through the main entry authentication 00:04:32.899 --> 00:04:36.939 improvements in SQL Server 2025. Oh, yeah, sure. 00:04:37.540 --> 00:04:39.959 So, Michael, as you'd already be knowing, we 00:04:39.959 --> 00:04:44.000 have a pretty big push that we do not want to 00:04:44.000 --> 00:04:46.600 use passwords. I mean, Hantra is there from a 00:04:46.600 --> 00:04:49.500 long, long time. uh but not for the our customers 00:04:49.500 --> 00:04:52.579 that much i if if you have tried in sql server 00:04:52.579 --> 00:04:56.240 2022 which is an on -prem though you can enable 00:04:56.240 --> 00:04:59.379 entra and you can remove sql logins which use 00:04:59.379 --> 00:05:02.319 passwords but you still rely on credentials like 00:05:02.319 --> 00:05:06.120 certificates to set the entra so in a way the 00:05:06.120 --> 00:05:08.139 passwords are gone but you are still relying 00:05:08.139 --> 00:05:10.939 on some kind of credential right that can be 00:05:10.939 --> 00:05:13.360 stolen and hacked and whatnot right but with 00:05:13.360 --> 00:05:18.279 2025 on arc enabled machines you would not even 00:05:18.279 --> 00:05:21.500 need a credential to start up your Entra authentication 00:05:21.500 --> 00:05:25.000 on SQL. There's a managed identity that's provisioned 00:05:25.000 --> 00:05:27.980 by the Arc agent itself. So what I mean is as 00:05:27.980 --> 00:05:30.459 soon as your Windows VM in an on -prem system 00:05:30.459 --> 00:05:33.959 is Arc enabled, you get a managed identity provision. 00:05:34.279 --> 00:05:37.459 So that VM is actually registered with Entra 00:05:37.459 --> 00:05:41.500 servers. And now in SQL 2025, we have taught 00:05:41.500 --> 00:05:44.939 SQL Server to use that identity and speak to 00:05:45.449 --> 00:05:48.709 on the service to authenticate any users and 00:05:48.709 --> 00:05:51.829 logins. On top of that, you can also use that 00:05:51.829 --> 00:05:54.170 identity for out -mount connections. For example, 00:05:54.329 --> 00:05:57.569 you want to take a backup from SQL database to 00:05:57.569 --> 00:06:00.170 Azure storage maybe, you don't have to use any 00:06:00.170 --> 00:06:03.689 SAS keys or anything for the storage. You can 00:06:03.689 --> 00:06:06.550 use that identity, give that identity a block 00:06:06.550 --> 00:06:08.790 contributor access, the usual thing that you 00:06:08.790 --> 00:06:11.860 do for the storage access. and there you go using 00:06:11.860 --> 00:06:14.439 a backup restore usual commands and a create 00:06:14.439 --> 00:06:17.779 credential manage identity is equal credential 00:06:17.779 --> 00:06:19.620 free you can take backups and you can restore 00:06:19.620 --> 00:06:22.079 backups so this is one of the example that that 00:06:22.079 --> 00:06:25.040 we are pushing forward you can also use ekm for 00:06:25.040 --> 00:06:28.839 that so yeah i mean this is an effort that we 00:06:28.839 --> 00:06:32.720 keep on we plan to keep on doing it uh push forward 00:06:32.720 --> 00:06:35.199 for every feature not to use any kind of credential 00:06:36.119 --> 00:06:37.959 So I just want to ask you a question about the 00:06:37.959 --> 00:06:39.819 managed identity and just about the lack of credentials. 00:06:39.939 --> 00:06:42.199 So I'm sort of in a bit of a unique position 00:06:42.199 --> 00:06:44.540 here because, first of all, I used to work in 00:06:44.540 --> 00:06:47.079 the Azure Data team, so very familiar with SQL 00:06:47.079 --> 00:06:49.420 Server and so on. But now I work in the Red team, 00:06:49.540 --> 00:06:52.540 and the first thing that we go hunting for is 00:06:52.540 --> 00:06:54.620 credentials, right? I mean, if we can find credentials, 00:06:54.639 --> 00:06:57.000 then that lets us traverse across the network. 00:06:57.620 --> 00:07:00.120 And a lot of the credential work or removing 00:07:00.120 --> 00:07:02.079 credentials that are being done across the company 00:07:02.800 --> 00:07:04.720 are there because of the secure future initiative 00:07:04.720 --> 00:07:06.620 work, which is removing credentials from the 00:07:06.620 --> 00:07:10.360 environment. So is this an example of removing 00:07:10.360 --> 00:07:12.560 credentials from the environment to sort of help 00:07:12.560 --> 00:07:16.839 with the SFI requirements? Yes. So that is one 00:07:16.839 --> 00:07:20.500 of the prime motto, that any service or every 00:07:20.500 --> 00:07:23.740 service that Microsoft provisions and it's customer 00:07:23.740 --> 00:07:27.259 facing or not, we do not want folks like you, 00:07:27.319 --> 00:07:29.319 me, or any user to manage their own credential. 00:07:30.829 --> 00:07:32.709 And it's not limited to passwords. It's anything, 00:07:32.889 --> 00:07:35.069 any artifact that can be used to authenticate. 00:07:35.689 --> 00:07:39.149 We've had issues where we've found, you know, 00:07:39.149 --> 00:07:42.310 SaaS tokens that have led to essentially exploitation 00:07:42.310 --> 00:07:45.069 of storage accounts. So yeah, anything where 00:07:45.069 --> 00:07:48.589 a credential is persisted is a number one target 00:07:48.589 --> 00:07:51.129 of attackers. So it's magnificent to see SQL 00:07:51.129 --> 00:07:53.170 Server, you know, going above and beyond to make 00:07:53.170 --> 00:07:56.089 sure that these things are removed. Yes. So it's 00:07:56.089 --> 00:07:59.449 not completely new. So if you were a VM customer, 00:07:59.649 --> 00:08:02.529 like, completely Azure customer, you're already 00:08:02.529 --> 00:08:05.290 using Azure VMs, you could have done it in SQL 00:08:05.290 --> 00:08:09.269 2022. So 2022 and Azure VMs already knew how 00:08:09.269 --> 00:08:11.709 to use managed identities, but then we are just 00:08:11.709 --> 00:08:13.470 restricting every customer to come to Azure. 00:08:13.949 --> 00:08:16.930 With this effort, even the customers who are 00:08:16.930 --> 00:08:19.649 not in Azure shop, just an on -prem shop, can 00:08:19.649 --> 00:08:22.629 actually take use of this. So it's an effort 00:08:22.629 --> 00:08:24.930 to secure everybody, I'd say. All right. Well, 00:08:24.949 --> 00:08:26.310 that's the internal authentication stuff out 00:08:26.310 --> 00:08:28.629 of the way. That was short and sweet. But again, 00:08:28.750 --> 00:08:30.850 I really want to stress, I think these changes 00:08:30.850 --> 00:08:34.309 are really important. I mean, as a world, we 00:08:34.309 --> 00:08:36.029 need to get away from these sort of credentials 00:08:36.029 --> 00:08:38.450 that can be persisted somewhere because, again, 00:08:38.529 --> 00:08:40.830 the attackers go after them. All right, so the 00:08:40.830 --> 00:08:43.570 next thing is cryptographic updates, and I think 00:08:43.570 --> 00:08:46.009 that's where you come in, Peter. Yep, that's 00:08:46.009 --> 00:08:50.009 right. Most of the crypto updates, the users 00:08:50.009 --> 00:08:52.529 of SQL Server 2025, they won't even probably 00:08:52.529 --> 00:08:55.970 notice it because... We're doing some stuff under 00:08:55.970 --> 00:08:58.409 the covers. Well, if you would look in system 00:08:58.409 --> 00:09:01.789 tables, you will notice that we're using different 00:09:01.789 --> 00:09:04.850 types of algorithms and better algorithms. But 00:09:04.850 --> 00:09:07.830 yeah, mainly the users, they will not notice 00:09:07.830 --> 00:09:11.629 it that we have made SQL Server even stronger 00:09:11.629 --> 00:09:15.190 on security level. The first one, what we've 00:09:15.190 --> 00:09:18.149 done, Michael, and you're probably familiar with 00:09:18.149 --> 00:09:22.529 it, is the PBKDF for password hashes. We've enabled 00:09:22.529 --> 00:09:28.610 this. by default in SQL Server 2025. So what 00:09:28.610 --> 00:09:32.250 we did in previous versions of SQL, we were using 00:09:32.250 --> 00:09:38.330 a SHA -512 hash with a 32 -bit random and a unique 00:09:38.330 --> 00:09:43.009 salt. So that was a pretty good method to make 00:09:43.009 --> 00:09:46.789 it impossible for hackers to fetch passwords 00:09:46.789 --> 00:09:51.370 that are stored in SQL Server. Now what we've 00:09:51.370 --> 00:09:55.159 done is we're using that new algorithm, so the 00:09:55.159 --> 00:10:00.759 PVKDF. And we're still using that SHA -512 hash, 00:10:01.000 --> 00:10:03.679 but we're hashing the password. Instead of one 00:10:03.679 --> 00:10:06.320 time, we're hashing it multiple times, like 100 00:10:06.320 --> 00:10:11.279 ,000 iterations, which significantly is slowing 00:10:11.279 --> 00:10:14.820 down brute force attacks, of course, by using 00:10:14.820 --> 00:10:18.240 this. How will customers... know that they're 00:10:18.240 --> 00:10:21.879 using this new functionality. Well, if you look 00:10:21.879 --> 00:10:26.679 at the passwords that are stored in the SQL login 00:10:26.679 --> 00:10:29.659 system table, you will notice that the first 00:10:29.659 --> 00:10:32.960 byte is the version of the algorithm that is 00:10:32.960 --> 00:10:35.740 used. And in SQL Server 2025, that is going to 00:10:35.740 --> 00:10:40.320 be 03. If you still see 02, then it means that 00:10:40.320 --> 00:10:44.259 you're using the old algorithm here. A little 00:10:44.259 --> 00:10:46.720 bit of context to this, as you kind of mentioned. 00:10:47.360 --> 00:10:50.460 I was actually the PM for this particular feature 00:10:50.460 --> 00:10:53.379 back in the day when we first implemented it. 00:10:53.620 --> 00:10:55.159 So it was actually a requirement that came in 00:10:55.159 --> 00:10:57.419 from a very large bank in the US who needed it 00:10:57.419 --> 00:11:00.059 for compliance reasons. So we worked closely 00:11:00.059 --> 00:11:03.100 with the customer and we produced a version, 00:11:03.179 --> 00:11:06.000 as you mentioned, it's a PBKTF, stands for password 00:11:06.000 --> 00:11:08.840 -based key derivation function. And we iterate 00:11:08.840 --> 00:11:12.940 over the hash or the originating password. And 00:11:12.940 --> 00:11:14.820 as you say, a unique salt. I'm so glad you said 00:11:14.820 --> 00:11:17.440 unique salt. A lot of people say random salt. 00:11:17.659 --> 00:11:19.500 It doesn't have to be random. It has to be unique. 00:11:20.159 --> 00:11:23.039 So using a unique salt and a random password, 00:11:23.120 --> 00:11:24.679 and obviously a random password, hopefully a 00:11:24.679 --> 00:11:27.220 random password, and then iterate over that 100 00:11:27.220 --> 00:11:29.080 ,000 times, which, by the way, at Microsoft is 00:11:29.080 --> 00:11:32.370 the... lower limit under the microsoft security 00:11:32.370 --> 00:11:35.210 development life cycle for pbkdfs and then we 00:11:35.210 --> 00:11:37.950 store that result and historically it was it 00:11:37.950 --> 00:11:40.830 was there in sql server 2025 but we hid it behind 00:11:40.830 --> 00:11:44.649 a trace flag so it was off by default and uh 00:11:44.649 --> 00:11:47.070 yeah it's nice to see this on by default and 00:11:47.070 --> 00:11:49.330 as you mentioned you know this is version three 00:11:49.330 --> 00:11:52.350 hence the first byte is zero three and but we 00:11:52.350 --> 00:11:54.830 only change make sure is this correct i assume 00:11:54.830 --> 00:11:57.820 this is the case we don't auto -migrate from 00:11:57.820 --> 00:11:59.860 version 2 to version 3? Because we can't, because 00:11:59.860 --> 00:12:02.259 we don't have the password, right? Yeah, that's 00:12:02.259 --> 00:12:04.759 a good question, Michael. What we do, sorry to 00:12:04.759 --> 00:12:07.919 interrupt you, is when you migrate a login or 00:12:07.919 --> 00:12:11.440 you script a login from SQL 2022 and you run 00:12:11.440 --> 00:12:15.139 that script on SQL 2025, we will still use the 00:12:15.139 --> 00:12:19.360 old algorithm. Until you do an alter login and 00:12:19.360 --> 00:12:22.360 you change the password, then we will start using 00:12:22.360 --> 00:12:25.159 the new algorithm. If you don't change anything, 00:12:25.480 --> 00:12:28.019 we will still use the old algorithm. So it's 00:12:28.019 --> 00:12:30.940 transparent if you migrate logins. And that's 00:12:30.940 --> 00:12:33.700 just so incredibly important because we don't 00:12:33.700 --> 00:12:36.580 have the password, so we can't generate the new 00:12:36.580 --> 00:12:39.600 password verifier, right? So we don't store the 00:12:39.600 --> 00:12:41.639 password. We store the verifier of the password. 00:12:42.019 --> 00:12:44.279 Correct. That's good. Okay, that's great news. 00:12:44.440 --> 00:12:46.740 All right, what else we got? The second one that 00:12:46.740 --> 00:12:50.600 we have is the OAP support for certificates and 00:12:50.600 --> 00:12:55.210 asymmetric keys. Azure SQL and SQL Server, the 00:12:55.210 --> 00:12:59.049 RSA algorithm is used for asymmetric encryption. 00:13:00.649 --> 00:13:04.850 But the RSA algorithm cannot be used in its pure 00:13:04.850 --> 00:13:08.990 form. So what we're doing to achieve security, 00:13:09.090 --> 00:13:13.309 these messages, they require padding, right? 00:13:14.110 --> 00:13:18.350 So currently, we're using or the data is encrypted 00:13:18.350 --> 00:13:23.870 with RSA using the PKCS version 1 .5, but that 00:13:23.870 --> 00:13:28.950 has a specific weakness, right? So what we've 00:13:28.950 --> 00:13:32.070 did is we upgraded it to a newer version with 00:13:32.070 --> 00:13:35.450 a new padding type called Optimal Asymmetric 00:13:35.450 --> 00:13:40.429 Encryption Padding or the OAEP, right? So that 00:13:40.429 --> 00:13:43.629 introduces some hashing between the RSA encryption 00:13:43.629 --> 00:13:46.950 and the padding check, right? which makes it 00:13:46.950 --> 00:13:50.750 significantly much more difficult for an attacker 00:13:50.750 --> 00:13:54.610 to understand what they can see. Yeah, there's 00:13:54.610 --> 00:13:56.549 a really nasty vulnerability called a padding 00:13:56.549 --> 00:14:01.629 oracle attack. And OAEP essentially mitigates 00:14:01.629 --> 00:14:03.950 that, which is good. Always a good thing. Yeah. 00:14:04.389 --> 00:14:07.710 Again, something you cannot see unless you look 00:14:07.710 --> 00:14:10.769 in a system table called key encryptions, where 00:14:10.769 --> 00:14:13.990 you will see that the certificate or the asymmetric 00:14:13.990 --> 00:14:18.259 key Sorry, the key that is encrypted by the certificate 00:14:18.259 --> 00:14:22.480 or the asymmetric key is using that OAP. So on 00:14:22.480 --> 00:14:24.639 that topic of OAP, I mean, do we add that because 00:14:24.639 --> 00:14:26.799 it's a fun thing to do or do we actually add 00:14:26.799 --> 00:14:30.159 it because customers ask for it, compliance reasons, 00:14:30.360 --> 00:14:33.620 modern threats, all of the above? Yes, all of 00:14:33.620 --> 00:14:36.820 the above, Michael. Okay, fair enough. We just 00:14:36.820 --> 00:14:39.720 wanted to make it better and stronger as always. 00:14:39.779 --> 00:14:43.879 So we are the most secure database platform. 00:14:44.639 --> 00:14:46.720 So yeah, we wanted to make it even stronger. 00:14:46.919 --> 00:14:48.879 And that's the reason also why we implemented 00:14:48.879 --> 00:14:55.059 this. So the next topic is TDS 8, TLS 1 .3 support, 00:14:55.159 --> 00:14:57.840 which is one of my favorite topics. So do you 00:14:57.840 --> 00:15:00.019 care to go into some depth about that? SQL Server 00:15:00.019 --> 00:15:06.279 2022 already supported TDS 8 .0. So you could 00:15:06.279 --> 00:15:10.399 use an extra parameter in your connection string. 00:15:10.519 --> 00:15:14.549 This encryption equals strict. which means that 00:15:14.549 --> 00:15:20.029 at that point, you were using TDS 8 .0. On the 00:15:20.029 --> 00:15:22.750 other hand, you also had to upgrade your drivers. 00:15:22.889 --> 00:15:26.210 But anyway, we already supported it. The problem 00:15:26.210 --> 00:15:29.750 was, Michael, that in SQL 2022, all our internal 00:15:29.750 --> 00:15:37.029 features like SQL agents, like BCP, always -on 00:15:37.029 --> 00:15:39.409 availability groups, all these features, they 00:15:39.409 --> 00:15:43.539 were not using TDS 8 .0. So we wanted to address 00:15:43.539 --> 00:15:48.720 this problem. And now in SQL Server 2025, all 00:15:48.720 --> 00:15:52.720 our internal features will support TDS 8 .0. 00:15:52.820 --> 00:15:54.960 We're not there yet. So we're still in public 00:15:54.960 --> 00:15:59.159 preview. And some of the features like SQL command 00:15:59.159 --> 00:16:02.480 and BCP, they already support it. But the others 00:16:02.480 --> 00:16:08.139 will come later, probably by GA. But for sure, 00:16:08.240 --> 00:16:13.720 they will all use TDS 8 .0. And so for clarification, 00:16:14.080 --> 00:16:16.600 so TDS is tabular data stream, right? Which is 00:16:16.600 --> 00:16:19.120 the native SQL server communications protocol 00:16:19.120 --> 00:16:22.159 on the network. That's right. Yeah. Okay. And 00:16:22.159 --> 00:16:24.419 then TLS is just, well, hopefully we all know 00:16:24.419 --> 00:16:27.100 what TLS is at this point. And just a little 00:16:27.100 --> 00:16:29.580 bit of history. So back in the day, so prior 00:16:29.580 --> 00:16:33.440 to TDS 8, there were some very strong interdependencies 00:16:33.440 --> 00:16:37.620 between TDS prior to 8 and TLS that made it really, 00:16:37.720 --> 00:16:41.720 really difficult to upgrade TLS protocol versions 00:16:41.720 --> 00:16:45.580 to more modern versions. So now we've done all 00:16:45.580 --> 00:16:48.500 that hard work to break the two apart and break 00:16:48.500 --> 00:16:51.220 the dependencies. So now they can be essentially 00:16:51.220 --> 00:16:53.620 upgraded independently, which is really good 00:16:53.620 --> 00:16:55.019 news, which is the way it should be, right? It 00:16:55.019 --> 00:16:58.379 really should just be the same way HTTPS works, 00:16:58.700 --> 00:17:01.720 right? We can upgrade HTTP if we wanted to underneath 00:17:01.720 --> 00:17:05.380 the covers. We can use... 1 .0, 1 .1, 2 .0, whatever, 00:17:05.660 --> 00:17:10.140 and then just change the TLS protocol version 00:17:10.140 --> 00:17:13.640 at will. And luckily, we're in a position like 00:17:13.640 --> 00:17:17.019 that now with TDS, which is great to see. Good 00:17:17.019 --> 00:17:21.619 news. All right, last one is security cache improvements. 00:17:21.759 --> 00:17:25.640 What the heck is that? Yeah, that's a known problem 00:17:25.640 --> 00:17:30.279 that existed for years that we finally resolved. 00:17:30.720 --> 00:17:35.480 And the problem is, well, Every time that a user 00:17:35.480 --> 00:17:39.440 or a login makes a connection to SQL Server, 00:17:39.519 --> 00:17:42.440 what we're doing is we're storing all these permissions 00:17:42.440 --> 00:17:45.880 of the users and the logins in the security cache. 00:17:46.099 --> 00:17:49.259 One of the benefits of storing that in the cache 00:17:49.259 --> 00:17:51.619 is, of course, it's speeding up the query execution. 00:17:54.480 --> 00:17:59.079 Now, the problem is that if... there are certain 00:17:59.079 --> 00:18:02.400 actions that will invalidate that security cache. 00:18:02.559 --> 00:18:05.380 For example, if you create a new login on the 00:18:05.380 --> 00:18:08.480 server or if you change the permissions of a 00:18:08.480 --> 00:18:12.579 specific login, if you drop a login. Either way, 00:18:12.640 --> 00:18:15.660 so all these actions will invalidate the cache 00:18:15.660 --> 00:18:20.240 and what I mean by that is it will invalidate 00:18:20.240 --> 00:18:22.759 the cache of the whole database or the whole 00:18:22.759 --> 00:18:26.180 server, depending if it's a login or a database 00:18:26.180 --> 00:18:30.839 permission that you've changed. Now, this means 00:18:30.839 --> 00:18:34.900 that every single connection that is open at 00:18:34.900 --> 00:18:37.839 that point to your instance will need to rebuild 00:18:37.839 --> 00:18:42.000 the security cache from scratch, right? And this 00:18:42.000 --> 00:18:44.579 can significantly impact the performance on the 00:18:44.579 --> 00:18:47.180 server, right? If you just have a couple of connections, 00:18:47.380 --> 00:18:50.240 no worries, you won't see any difference. But 00:18:50.240 --> 00:18:53.980 if you have like thousands of connections that 00:18:53.980 --> 00:18:58.079 needs to rebuild all their cache entries, yeah, 00:18:58.220 --> 00:19:01.440 definitely you will notice some performance impact. 00:19:02.500 --> 00:19:05.680 So what we've done, Michael, we addressed that 00:19:05.680 --> 00:19:08.839 problem and currently in SQL Server... 2025, 00:19:09.299 --> 00:19:13.180 we're only invalidating the cache for a specific 00:19:13.180 --> 00:19:16.059 login. Let's say the three of us, we have a login 00:19:16.059 --> 00:19:19.559 and I change a permission in my login. It means 00:19:19.559 --> 00:19:23.319 that my cache will be invalidated, but not yours 00:19:23.319 --> 00:19:27.579 and not the cache of Protein, which, yeah, of 00:19:27.579 --> 00:19:32.000 course, reduces that performance impact. Currently, 00:19:32.220 --> 00:19:36.519 it applies to create and drop login scenarios 00:19:36.519 --> 00:19:40.759 and permissive changes on individual logins. 00:19:41.420 --> 00:19:44.799 We're currently in public preview. By GA, we 00:19:44.799 --> 00:19:49.119 should also cover alter login as well. For group 00:19:49.119 --> 00:19:52.400 logins, so it only works currently for individual 00:19:52.400 --> 00:19:56.000 logins. For group logins, you will continue to 00:19:56.000 --> 00:19:59.519 experience the server level invalidations. We're 00:19:59.519 --> 00:20:02.339 working on that and probably, yeah, we don't 00:20:02.339 --> 00:20:06.019 have any timeline yet, but probably it will be 00:20:06.019 --> 00:20:09.960 released in one of the next CU updates that we 00:20:09.960 --> 00:20:13.460 will do on SQL Server 2025. But yeah, huge improvement 00:20:13.460 --> 00:20:17.079 here and a lot of our customers will be happy 00:20:17.079 --> 00:20:19.920 with this improvement. So a couple of things. 00:20:20.019 --> 00:20:21.759 So first of all, CU being cumulative update. 00:20:22.180 --> 00:20:26.440 Yes. And so is it, are you saying it's always 00:20:26.440 --> 00:20:29.500 been this way until like? SQL Server 2025? My 00:20:29.500 --> 00:20:31.819 goodness. So that must have caused like huge, 00:20:31.859 --> 00:20:35.700 my guess is this was a real nagging customer 00:20:35.700 --> 00:20:38.859 pain point, support pain point. Yeah, yeah, definitely. 00:20:39.299 --> 00:20:42.900 Wow. Support team, they had lots of incidents 00:20:42.900 --> 00:20:47.059 because of that. Yeah. And my guess is it probably 00:20:47.059 --> 00:20:48.900 wasn't a very easy fix. That's why it probably 00:20:48.900 --> 00:20:51.259 took a while to get done. Yeah, that's right. 00:20:51.460 --> 00:20:54.839 Yeah. And still is. Yeah. So command by command, 00:20:54.940 --> 00:20:57.440 because there are lots of commands that, are 00:20:57.440 --> 00:21:00.700 triggering and securing the cache invalidation. 00:21:00.799 --> 00:21:03.319 So we need to cover them both. So we currently, 00:21:03.579 --> 00:21:07.240 like I said, we have create and drop and alter 00:21:07.240 --> 00:21:10.119 login, but there are plenty more like create 00:21:10.119 --> 00:21:13.240 application role or create certificates also 00:21:13.240 --> 00:21:15.980 invalidates the cache. So yeah, we still have 00:21:15.980 --> 00:21:18.319 some work to do, Michael. Wow. That's good to 00:21:18.319 --> 00:21:21.630 see though. I mean... I mean, anything that improves 00:21:21.630 --> 00:21:23.890 performance and improves security at the same 00:21:23.890 --> 00:21:26.789 time is always a good thing. Yes. All righty. 00:21:27.309 --> 00:21:30.190 So one thing we started asking our guests, probably 00:21:30.190 --> 00:21:32.390 started just a couple of months ago now, is, 00:21:32.490 --> 00:21:34.750 so what does a typical day look like? When you 00:21:34.750 --> 00:21:36.970 come to work, what does a typical day look like? 00:21:37.210 --> 00:21:39.630 Every day before I sleep, I try to see what I 00:21:39.630 --> 00:21:42.710 have in the next day's meeting. And for whatever 00:21:42.710 --> 00:21:45.170 reason, every day starts different. As soon as 00:21:45.170 --> 00:21:47.349 I open my emails, there are a bunch of emails 00:21:47.349 --> 00:21:49.509 that I'll have to answer and then go to meetings. 00:21:49.930 --> 00:21:53.509 And long story short, every day is a little bit 00:21:53.509 --> 00:21:56.269 different. But the vanilla part is you have a 00:21:56.269 --> 00:21:58.549 bunch of meetings, meet with people, answer customer 00:21:58.549 --> 00:22:00.970 queries, and then take some time to write specs, 00:22:01.450 --> 00:22:04.950 update customer documentations, speak with engineering 00:22:04.950 --> 00:22:07.230 to see what issues are going on, if we are on 00:22:07.230 --> 00:22:09.990 the time for deliveries, and if you get some 00:22:09.990 --> 00:22:12.799 time. then read about new features that we should 00:22:12.799 --> 00:22:15.579 be doing and what our competitors are doing and 00:22:15.579 --> 00:22:18.920 whatnot and read to them and hear podcasts, see 00:22:18.920 --> 00:22:22.119 videos so that I learn. It's a mixed bag, I'd 00:22:22.119 --> 00:22:25.900 say. My day starts with a coffee. I cannot start 00:22:25.900 --> 00:22:28.720 without coffee. So first things first, coffee. 00:22:29.519 --> 00:22:32.500 I'm in a different time zone than Protein and 00:22:32.500 --> 00:22:35.079 my other colleagues. So I'm based in Europe, 00:22:35.200 --> 00:22:38.460 which is a huge advantage for me because when 00:22:38.460 --> 00:22:41.990 I start my... working day everybody else is asleep 00:22:41.990 --> 00:22:47.289 so I can do I can yeah read all the emails I 00:22:47.289 --> 00:22:51.490 can prepare the the next meetings for the day 00:22:51.490 --> 00:22:54.710 I can I never get disturbed right I just can 00:22:54.710 --> 00:22:58.970 do whatever I want I don't get any well not that 00:22:58.970 --> 00:23:02.569 many emails during the day so what I do I typically 00:23:02.569 --> 00:23:06.400 work Around my noon time, then sometimes I just 00:23:06.400 --> 00:23:10.619 go for a run or go out to walk with my dog. And 00:23:10.619 --> 00:23:14.759 then I start again at 3, 4 in the afternoon with 00:23:14.759 --> 00:23:18.720 all the calls that I have with people in Redmond, 00:23:18.799 --> 00:23:24.200 with engineering, with other PMs currently working 00:23:24.200 --> 00:23:28.500 on customer managed key and fabric, which takes 00:23:28.500 --> 00:23:31.750 a lot of my time. working on SQL Server 2025, 00:23:32.329 --> 00:23:36.369 preparing presentations and stuff like that. 00:23:36.509 --> 00:23:41.250 So, yeah, that's how my life looks like. I like 00:23:41.250 --> 00:23:43.349 the team that you said, you know, you're very 00:23:43.349 --> 00:23:45.910 conscious of making sure you stay on top of things. 00:23:46.470 --> 00:23:49.450 I think that's really important, you know, carve 00:23:49.450 --> 00:23:51.589 out some time to sort of learn, you know, new 00:23:51.589 --> 00:23:53.410 stuff. All right, so let's bring this episode 00:23:53.410 --> 00:23:56.650 to an end. So we like to ask, I guess, something 00:23:56.650 --> 00:23:58.859 we've done since the very beginning. is if you 00:23:58.859 --> 00:24:01.259 had just one final thought to leave our listeners 00:24:01.259 --> 00:24:03.779 with, and what would it be? Yeah, I can get started 00:24:03.779 --> 00:24:06.519 with it. So because SQL 2025, the Entra features 00:24:06.519 --> 00:24:09.720 are ARC dependent. So I would say if one of our 00:24:09.720 --> 00:24:11.559 customers is trying it, they should make sure 00:24:11.559 --> 00:24:14.420 that the ARC extensions and the SQL ARC extensions 00:24:14.420 --> 00:24:17.940 are the latest ones so that they don't run into 00:24:17.940 --> 00:24:20.680 some random issues. All right. And I would say 00:24:20.680 --> 00:24:24.500 we've made SQL 2025 even more secure. So we did 00:24:24.500 --> 00:24:28.319 a couple of crypto updates. We've done updates 00:24:28.319 --> 00:24:31.940 on the security cache. So yeah, we always say 00:24:31.940 --> 00:24:35.059 secure by default. And that is still true. And 00:24:35.059 --> 00:24:38.799 last but not least, go download SQL Server and 00:24:38.799 --> 00:24:42.500 just try it out yourself. Very cool. All right, 00:24:42.500 --> 00:24:44.680 so let's now officially bring this episode to 00:24:44.680 --> 00:24:46.079 an end. Gentlemen, thank you so much for joining 00:24:46.079 --> 00:24:48.339 me this week. I know you guys are both very, 00:24:48.400 --> 00:24:49.940 very busy, so I appreciate you taking the time. 00:24:50.240 --> 00:24:52.240 And to all our listeners out there, we hope you 00:24:52.240 --> 00:24:54.700 found this episode useful. Stay safe, and we'll 00:24:54.700 --> 00:24:56.160 see you next time. Thanks for listening to the 00:24:56.160 --> 00:24:59.059 Azure Security Podcast. You can find show notes 00:24:59.059 --> 00:25:03.019 and other resources at our website, azsecuritypodcast 00:25:03.019 --> 00:25:06.819 .net. If you have any questions, please find 00:25:06.819 --> 00:25:10.240 us on Twitter at AzureSecPod. Background music 00:25:10.240 --> 00:25:13.619 is from ccmixter .com and licensed under the 00:25:13.619 --> 00:25:14.960 Creative Commons License.