1 00:00:00,000 --> 00:00:01,920 Your Azure SQL Firewall is lying to you, 2 00:00:01,920 --> 00:00:04,640 while you're relying on static rules and service principles, 3 00:00:04,640 --> 00:00:06,960 attackers are already bypassing your perimeter 4 00:00:06,960 --> 00:00:09,800 to exploit over-privileged accounts. 5 00:00:09,800 --> 00:00:12,280 The legacy assumption that a firewall equal safety 6 00:00:12,280 --> 00:00:13,520 is officially broken. 7 00:00:13,520 --> 00:00:15,600 Most Azure SQL environments are currently built 8 00:00:15,600 --> 00:00:19,880 on a 1990s trust model operating in a 2026 threat landscape. 9 00:00:19,880 --> 00:00:22,040 Your network boundaries are no longer a shield. 10 00:00:22,040 --> 00:00:23,400 They've become a blindfold. 11 00:00:23,400 --> 00:00:25,720 We are looking at why Saturn forget firewall rules 12 00:00:25,720 --> 00:00:28,920 are the primary reason for modern audit failures. 13 00:00:28,920 --> 00:00:30,040 In the next 24 minutes, 14 00:00:30,040 --> 00:00:31,760 we are dismantling the network perimeter 15 00:00:31,760 --> 00:00:33,600 to build an identity-based stronghold. 16 00:00:33,600 --> 00:00:35,280 If you don't move beyond static IPs, 17 00:00:35,280 --> 00:00:37,320 you aren't just behind the curve, you are the target. 18 00:00:37,320 --> 00:00:39,240 But to understand why the firewall is failing, 19 00:00:39,240 --> 00:00:42,520 we have to look at the structural decay of the traditional model. 20 00:00:42,520 --> 00:00:44,480 The erosion of the static perimeter, 21 00:00:44,480 --> 00:00:46,840 the secure network was designed for a world 22 00:00:46,840 --> 00:00:49,200 where people knew exactly what they were looking for. 23 00:00:49,200 --> 00:00:51,240 You had a server, you had a known IP, 24 00:00:51,240 --> 00:00:53,880 you drew a line around it, that assumption is broken. 25 00:00:53,880 --> 00:00:56,080 Because today, work doesn't start with navigation, 26 00:00:56,080 --> 00:00:57,440 it starts with context, 27 00:00:57,440 --> 00:00:59,960 but our SQL firewalls still start with IP ranges. 28 00:00:59,960 --> 00:01:01,640 This is the model behind the failure. 29 00:01:01,640 --> 00:01:04,200 Static IP white listing is a legacy mindset 30 00:01:04,200 --> 00:01:07,400 that fails the Dora 2026 compliance test. 31 00:01:07,400 --> 00:01:09,320 It assumes that being on the right network 32 00:01:09,320 --> 00:01:11,960 makes you trustworthy, but in reality, 33 00:01:11,960 --> 00:01:12,800 it does the opposite. 34 00:01:12,800 --> 00:01:15,600 It creates a hard shell with a soft, gooey center. 35 00:01:15,600 --> 00:01:18,080 The moment an attacker compromises a single workstation 36 00:01:18,080 --> 00:01:19,440 on your white-listed range, 37 00:01:19,440 --> 00:01:21,480 the firewall becomes their greatest ally. 38 00:01:21,480 --> 00:01:22,640 It stops looking at them. 39 00:01:22,640 --> 00:01:24,560 The 2024 Veronis vulnerability 40 00:01:24,560 --> 00:01:27,000 proved this floor isn't just theoretical, 41 00:01:27,000 --> 00:01:29,000 even secure firewall rule names were used 42 00:01:29,000 --> 00:01:30,200 for resource destruction. 43 00:01:30,200 --> 00:01:32,120 Attackers used T-Suckel manipulation 44 00:01:32,120 --> 00:01:35,160 to inject malicious parameters into the rule names themselves. 45 00:01:35,160 --> 00:01:36,560 When an admin tried to delete 46 00:01:36,560 --> 00:01:38,520 what looked like a benign rule in the portal, 47 00:01:38,520 --> 00:01:41,480 it triggered the deletion of arbitrary Azure resources. 48 00:01:41,480 --> 00:01:43,080 The tool meant to protect the database 49 00:01:43,080 --> 00:01:45,640 became the weapon used to destroy the subscription. 50 00:01:45,640 --> 00:01:47,480 And yet, many organizations are still clinging 51 00:01:47,480 --> 00:01:48,600 to the old ways. 52 00:01:48,600 --> 00:01:50,400 Basic public IPs and load balances 53 00:01:50,400 --> 00:01:52,840 reached end of life in late 2025. 54 00:01:52,840 --> 00:01:54,520 Microsoft gave years of warning, 55 00:01:54,520 --> 00:01:56,400 but many architectures haven't moved. 56 00:01:56,400 --> 00:01:57,840 They are running on borrowed time 57 00:01:57,840 --> 00:01:59,120 using retired infrastructure 58 00:01:59,120 --> 00:02:00,760 to protect life production data. 59 00:02:00,760 --> 00:02:02,320 It's the model that's the problem. 60 00:02:02,320 --> 00:02:04,680 Then there is the most common shortcut in the portal. 61 00:02:04,680 --> 00:02:06,560 The allow Azure Services checkbox. 62 00:02:06,560 --> 00:02:08,240 It's the ultimate illusion of security. 63 00:02:08,240 --> 00:02:09,760 You think you're allowing your app service 64 00:02:09,760 --> 00:02:11,240 to talk to your database. 65 00:02:11,240 --> 00:02:13,360 What you're actually doing is turning off your security 66 00:02:13,360 --> 00:02:14,760 for the sake of convenience. 67 00:02:14,760 --> 00:02:16,720 That checkbox doesn't just allow your services. 68 00:02:16,720 --> 00:02:19,000 It allows any service in the Azure Cloud 69 00:02:19,000 --> 00:02:21,320 to attempt a connection to your SQL gateway. 70 00:02:21,320 --> 00:02:22,840 You've effectively removed the parameter 71 00:02:22,840 --> 00:02:24,800 you spent months configuring in a world 72 00:02:24,800 --> 00:02:27,040 of automated scanning and AI driven brute force. 73 00:02:27,040 --> 00:02:28,400 That's not a configuration. 74 00:02:28,400 --> 00:02:30,440 It's an invitation. 75 00:02:30,440 --> 00:02:31,800 We are seeing a massive shift 76 00:02:31,800 --> 00:02:34,680 in how we define a safe connection. 77 00:02:34,680 --> 00:02:36,640 We are moving from a world of where you are 78 00:02:36,640 --> 00:02:38,200 to a world of who you are. 79 00:02:38,200 --> 00:02:40,160 Context is replacing location. 80 00:02:40,160 --> 00:02:42,160 Identity is replacing the IP address 81 00:02:42,160 --> 00:02:45,160 in the old model if you were inside the VNet you were trusted. 82 00:02:45,160 --> 00:02:47,920 In the new model, the VNet is just a transport layer. 83 00:02:47,920 --> 00:02:49,800 The trust is established at the request level. 84 00:02:49,800 --> 00:02:52,920 Every query, every login, every time. 85 00:02:52,920 --> 00:02:55,040 If you can't prove who is making the request, 86 00:02:55,040 --> 00:02:56,560 the network path doesn't matter. 87 00:02:56,560 --> 00:02:59,160 Because in reality, the network is already compromised. 88 00:02:59,160 --> 00:03:01,480 This erosion of the perimeter isn't a bad thing. 89 00:03:01,480 --> 00:03:02,960 It's a necessary evolution. 90 00:03:02,960 --> 00:03:04,480 We've spent decades building walls 91 00:03:04,480 --> 00:03:06,720 while the attackers were busy stealing the keys. 92 00:03:06,720 --> 00:03:08,920 By dismantling the myth of the secure network, 93 00:03:08,920 --> 00:03:11,280 we can finally focus on what actually matters. 94 00:03:11,280 --> 00:03:13,560 The data and the identities that touch it. 95 00:03:13,560 --> 00:03:16,760 Static rules are a shield made of paper in a world of fire. 96 00:03:16,760 --> 00:03:18,400 They provide a false sense of security 97 00:03:18,400 --> 00:03:20,960 while leaving the front door open to lateral movement. 98 00:03:20,960 --> 00:03:23,120 If an attacker gets inside, they stay inside. 99 00:03:23,120 --> 00:03:24,880 Because the firewall only looks at the entrance. 100 00:03:24,880 --> 00:03:26,360 It doesn't look at the behavior. 101 00:03:26,360 --> 00:03:28,040 It doesn't look at the intent. 102 00:03:28,040 --> 00:03:30,040 And it certainly doesn't look at the identity. 103 00:03:30,040 --> 00:03:31,600 This shift from location to identity 104 00:03:31,600 --> 00:03:34,400 leads us to the most dangerous component of your current setup. 105 00:03:34,400 --> 00:03:36,360 The service principle, it's the identity model 106 00:03:36,360 --> 00:03:38,240 that was supposed to solve our problems. 107 00:03:38,240 --> 00:03:40,680 But instead, it created a new kind of crisis, 108 00:03:40,680 --> 00:03:43,960 one that never sleeps and one that never expires. 109 00:03:43,960 --> 00:03:45,880 The identity crisis of service principles, 110 00:03:45,880 --> 00:03:48,160 service principles were supposed to be our salvation. 111 00:03:48,160 --> 00:03:50,920 They were the standard for a world moving toward automation. 112 00:03:50,920 --> 00:03:53,480 We needed a way for applications to talk to databases 113 00:03:53,480 --> 00:03:54,880 without a human in the middle. 114 00:03:54,880 --> 00:03:57,040 So we created these non-human identities. 115 00:03:57,040 --> 00:03:58,920 But in our rush to enable scale, 116 00:03:58,920 --> 00:04:01,520 we ignored the structural liability we were building. 117 00:04:01,520 --> 00:04:03,920 Today, the service principle is the single most dangerous 118 00:04:03,920 --> 00:04:06,160 component of your Azure SQL architecture. 119 00:04:06,160 --> 00:04:07,960 It isn't because the technology is flawed. 120 00:04:07,960 --> 00:04:09,680 It's because the management model is broken. 121 00:04:09,680 --> 00:04:13,040 We saw over 23 million secrets leaked on GitHub in 2024 alone. 122 00:04:13,040 --> 00:04:14,160 Think about that number. 123 00:04:14,160 --> 00:04:17,200 That's 23 million times a developer accidentally pushed 124 00:04:17,200 --> 00:04:18,960 a key to a public repository. 125 00:04:18,960 --> 00:04:21,360 And most of those were embedded database credentials. 126 00:04:21,360 --> 00:04:23,560 Connection strings, client secrets, passwords 127 00:04:23,560 --> 00:04:24,840 for service principles. 128 00:04:24,840 --> 00:04:26,640 In the old model, we treated these secrets 129 00:04:26,640 --> 00:04:28,200 like a one-time setup task. 130 00:04:28,200 --> 00:04:29,440 You generate the secret. 131 00:04:29,440 --> 00:04:31,000 You paste it into the config file. 132 00:04:31,000 --> 00:04:32,080 You forget about it. 133 00:04:32,080 --> 00:04:33,720 But the threat landscape doesn't forget 134 00:04:33,720 --> 00:04:36,560 traditional service principles hold standing indefinite 135 00:04:36,560 --> 00:04:38,040 privileges that never sleep. 136 00:04:38,040 --> 00:04:39,600 They don't have working hours. 137 00:04:39,600 --> 00:04:42,160 They don't have MFA prompts that a human can ignore. 138 00:04:42,160 --> 00:04:44,560 If an attacker finds that secret, they don't just get access. 139 00:04:44,560 --> 00:04:47,040 They get persistent silent access that looks exactly 140 00:04:47,040 --> 00:04:49,440 like legitimate application traffic. 141 00:04:49,440 --> 00:04:52,520 This leads us to the silent killers of Azure SQL Security, 142 00:04:52,520 --> 00:04:53,800 orphaned credentials. 143 00:04:53,800 --> 00:04:55,960 These are identities that outlive their projects, 144 00:04:55,960 --> 00:04:57,040 the developer leaves. 145 00:04:57,040 --> 00:04:58,680 The application is decommissioned. 146 00:04:58,680 --> 00:05:00,840 But the service principle remains in Enter ID. 147 00:05:00,840 --> 00:05:02,800 And it still has DB owner rights on your production 148 00:05:02,800 --> 00:05:03,840 SQL instance. 149 00:05:03,840 --> 00:05:05,360 It's a ghost in the machine. 150 00:05:05,360 --> 00:05:07,680 A dormant account with high privileged access, 151 00:05:07,680 --> 00:05:12,120 just waiting for a token validation failure like CVE 2025, 554, 152 00:05:12,120 --> 00:05:12,920 want to be exploited. 153 00:05:12,920 --> 00:05:14,640 That specific vulnerability proved 154 00:05:14,640 --> 00:05:17,440 that even global admin tokens can be impersonated. 155 00:05:17,440 --> 00:05:19,160 If an attacker can impersonate an identity 156 00:05:19,160 --> 00:05:21,000 that governs your service principles, 157 00:05:21,000 --> 00:05:22,680 your entire SQL estate is gone. 158 00:05:22,680 --> 00:05:24,480 The 2026 mandate is now clear. 159 00:05:24,480 --> 00:05:27,240 You must eliminate SQL authentication passwords entirely. 160 00:05:27,240 --> 00:05:29,840 The industry is moving toward a passwordless baseline. 161 00:05:29,840 --> 00:05:31,800 If your application still uses a connection string 162 00:05:31,800 --> 00:05:34,840 with a password, you have an unexploded bomb in your code. 163 00:05:34,840 --> 00:05:36,960 It's only a matter of time before that secret ends up 164 00:05:36,960 --> 00:05:39,840 in a log file, a backup, or a GitHub repo. 165 00:05:39,840 --> 00:05:42,040 The solution isn't better secret rotation. 166 00:05:42,040 --> 00:05:44,800 The solution is removing the secret from the equation. 167 00:05:44,800 --> 00:05:47,160 Managed identities are the only way 168 00:05:47,160 --> 00:05:49,560 to achieve a zero-standing privilege posture. 169 00:05:49,560 --> 00:05:51,880 Whether it's system assigned or user assigned, 170 00:05:51,880 --> 00:05:54,080 the managed identity removes the human element 171 00:05:54,080 --> 00:05:55,240 of credential management. 172 00:05:55,240 --> 00:05:56,600 There is no secret to leak. 173 00:05:56,600 --> 00:05:59,280 The password is handled by the Azure infrastructure itself. 174 00:05:59,280 --> 00:06:02,240 It's short-lived, it's automatically rotated. 175 00:06:02,240 --> 00:06:04,280 And most importantly, it's bound to the resource. 176 00:06:04,280 --> 00:06:07,000 An attacker can't just steal a managed identity secret 177 00:06:07,000 --> 00:06:08,520 and use it from their laptop. 178 00:06:08,520 --> 00:06:10,600 They would have to compromise the specific app service 179 00:06:10,600 --> 00:06:12,960 or function that the identity is bound to. 180 00:06:12,960 --> 00:06:14,840 This drastically reduces the blast radius 181 00:06:14,840 --> 00:06:16,320 of a credential compromise. 182 00:06:16,320 --> 00:06:17,880 But many architects hesitate. 183 00:06:17,880 --> 00:06:20,720 They worry about the complexity of migrating legacy apps. 184 00:06:20,720 --> 00:06:23,600 They think it's easier to just keep rotating passwords. 185 00:06:23,600 --> 00:06:25,880 But rotation is just a treadmill that never ends. 186 00:06:25,880 --> 00:06:28,360 It's a manual process in an automated world. 187 00:06:28,360 --> 00:06:30,640 And every manual process is a failure point. 188 00:06:30,640 --> 00:06:32,920 By shifting to managed identities, you aren't just 189 00:06:32,920 --> 00:06:34,120 improving security. 190 00:06:34,120 --> 00:06:35,800 You're improving operational resilience. 191 00:06:35,800 --> 00:06:37,320 You no longer have production outages 192 00:06:37,320 --> 00:06:40,160 because a service principle secret expired at 3.00 AM 193 00:06:40,160 --> 00:06:41,080 on a Sunday. 194 00:06:41,080 --> 00:06:43,200 You no longer have to worry about where your developers 195 00:06:43,200 --> 00:06:44,600 are storing their keys. 196 00:06:44,600 --> 00:06:46,720 The identity becomes a verifiable structural part 197 00:06:46,720 --> 00:06:47,360 of the workload. 198 00:06:47,360 --> 00:06:49,800 It's the first step in moving from trusting the network 199 00:06:49,800 --> 00:06:51,640 to verifying the identity. 200 00:06:51,640 --> 00:06:53,360 Removing the passwords is step one. 201 00:06:53,360 --> 00:06:55,680 But the real control happens when we change how we 202 00:06:55,680 --> 00:06:57,440 grant access in real time. 203 00:06:57,440 --> 00:07:00,520 We need to move beyond always on privileges, 204 00:07:00,520 --> 00:07:02,840 because even a managed identity shouldn't have access 205 00:07:02,840 --> 00:07:05,160 when it isn't working just in time. 206 00:07:05,160 --> 00:07:06,920 The end of standing privileges. 207 00:07:06,920 --> 00:07:10,520 Standing privileges are the roadmap attackers use for lateral movement. 208 00:07:10,520 --> 00:07:12,320 In most Azure SQL environments today, 209 00:07:12,320 --> 00:07:15,080 if you look at the SIS database, role members table, 210 00:07:15,080 --> 00:07:17,880 you'll see a list of accounts that have permanent 24/7 access 211 00:07:17,880 --> 00:07:19,200 to your most sensitive data. 212 00:07:19,200 --> 00:07:22,120 These are your DBAs, your developers, your automated maintenance 213 00:07:22,120 --> 00:07:22,640 scripts. 214 00:07:22,640 --> 00:07:24,960 They have the keys to the kingdom while they're sleeping. 215 00:07:24,960 --> 00:07:26,560 They have them while they're on vacation. 216 00:07:26,560 --> 00:07:28,680 They even have them while they're checking their personal email 217 00:07:28,680 --> 00:07:30,120 on a compromised home network. 218 00:07:30,120 --> 00:07:31,640 This is the definition of excessive risk. 219 00:07:31,640 --> 00:07:34,000 It's a model that assumes that because you needed access 220 00:07:34,000 --> 00:07:36,240 yesterday, you should have it forever. 221 00:07:36,240 --> 00:07:38,760 But in a zero trust world, forever is the enemy. 222 00:07:38,760 --> 00:07:41,880 We need to shift to a model where privileges only exist 223 00:07:41,880 --> 00:07:44,640 when there is a documented verified intent to use them. 224 00:07:44,640 --> 00:07:47,880 This is where just in time access or GIT changes the game. 225 00:07:47,880 --> 00:07:51,040 By leveraging Microsoft Entra privileged identity management, 226 00:07:51,040 --> 00:07:53,600 you can reduce your exposure window from forever 227 00:07:53,600 --> 00:07:55,080 to a matter of hours. 228 00:07:55,080 --> 00:07:56,520 Think about the math of risk. 229 00:07:56,520 --> 00:07:58,160 If an admin account is compromised 230 00:07:58,160 --> 00:07:59,840 and it has standing DBA owner rights, 231 00:07:59,840 --> 00:08:02,680 the attacker has an infinite window to exfiltrate data. 232 00:08:02,680 --> 00:08:05,520 But if that same admin is only eligible for the role, 233 00:08:05,520 --> 00:08:06,840 the attacker has nothing. 234 00:08:06,840 --> 00:08:08,880 They have a credential with zero permissions. 235 00:08:08,880 --> 00:08:12,080 To get to the data, they would have to trigger an activation request. 236 00:08:12,080 --> 00:08:13,760 That request requires a justification. 237 00:08:13,760 --> 00:08:15,760 It requires multi-factor authentication. 238 00:08:15,760 --> 00:08:17,240 And in high security environments, 239 00:08:17,240 --> 00:08:19,880 it requires a second human to hit the approve button. 240 00:08:19,880 --> 00:08:23,680 The window of opportunity shrinks from 8,760 hours a year 241 00:08:23,680 --> 00:08:24,760 to perhaps four. 242 00:08:24,760 --> 00:08:28,000 That is a 99.9% reduction in your attack surface. 243 00:08:28,000 --> 00:08:30,760 Implementing this for Azure SQL used to be a manual nightmare 244 00:08:30,760 --> 00:08:32,800 of T-Suckel scripts and scheduled jobs. 245 00:08:32,800 --> 00:08:36,240 But the 2025 PIM enhancements have streamlined the process 246 00:08:36,240 --> 00:08:38,000 through PIM-enabled groups. 247 00:08:38,000 --> 00:08:40,960 You no longer map individual users directly to SQL roles. 248 00:08:40,960 --> 00:08:43,000 Instead, you map an entrase security group 249 00:08:43,000 --> 00:08:45,920 to a database role like DBA data reader or DBA owner. 250 00:08:45,920 --> 00:08:47,200 The group is empty by default. 251 00:08:47,200 --> 00:08:49,720 When an engineer needs to troubleshoot a production issue, 252 00:08:49,720 --> 00:08:51,880 they activate their eligibility for that group. 253 00:08:51,880 --> 00:08:55,200 They are added to the group for a fixed duration, say two hours. 254 00:08:55,200 --> 00:08:57,520 Azure SQL recognizes the group membership 255 00:08:57,520 --> 00:08:58,880 and the engineer gets to work. 256 00:08:58,880 --> 00:09:00,760 The moment that two hour timer hits zero, 257 00:09:00,760 --> 00:09:02,760 Enter ID removes them from the group. 258 00:09:02,760 --> 00:09:04,120 Their access vanishes. 259 00:09:04,120 --> 00:09:07,640 The sleeping giant of their privileged account is put back to bed. 260 00:09:07,640 --> 00:09:09,120 This isn't just for humans. 261 00:09:09,120 --> 00:09:11,680 We are moving toward a world where high-privileged automation 262 00:09:11,680 --> 00:09:13,160 follows the same pattern. 263 00:09:13,160 --> 00:09:14,560 Why should your deployment pipeline 264 00:09:14,560 --> 00:09:16,880 have permanent right access to your production schema? 265 00:09:16,880 --> 00:09:17,720 It shouldn't. 266 00:09:17,720 --> 00:09:21,120 It should request JIT access at the start of the deployment 267 00:09:21,120 --> 00:09:23,440 and lose it the moment the pipeline completes. 268 00:09:23,440 --> 00:09:25,240 This prevents a compromised CI/CD runner 269 00:09:25,240 --> 00:09:27,760 from becoming a gateway for a total database takeover. 270 00:09:27,760 --> 00:09:29,280 And the system is getting smarter. 271 00:09:29,280 --> 00:09:32,480 The latest PIM enhancements now include AI-driven risk scoring. 272 00:09:32,480 --> 00:09:35,400 If an activation request comes from an anomalous location 273 00:09:35,400 --> 00:09:38,160 or a device that doesn't meet your compliance baseline, 274 00:09:38,160 --> 00:09:40,080 the system can auto-reject it. 275 00:09:40,080 --> 00:09:43,040 It moves us from a model of eligible means always available 276 00:09:43,040 --> 00:09:44,920 to a model of verified intent. 277 00:09:44,920 --> 00:09:46,800 You have to prove you are who you say you are 278 00:09:46,800 --> 00:09:49,240 on a device we trust for a reason we accept. 279 00:09:49,240 --> 00:09:51,960 Without JIT, a single compromised admin account 280 00:09:51,960 --> 00:09:54,160 represents a total tenant takeover 281 00:09:54,160 --> 00:09:57,000 with JIT is just a failed request in an audit log. 282 00:09:57,000 --> 00:09:59,000 But even with JIT, how do we ensure 283 00:09:59,000 --> 00:10:01,520 that the data itself is segmented within the environment? 284 00:10:01,520 --> 00:10:03,200 How do we stop an identity from seeing things 285 00:10:03,200 --> 00:10:04,760 it has no business touching? 286 00:10:04,760 --> 00:10:06,320 Access is only half the battle. 287 00:10:06,320 --> 00:10:08,680 The other half is isolation. 288 00:10:08,680 --> 00:10:10,560 Identity-based microsegmentation. 289 00:10:10,560 --> 00:10:12,360 Microsegmentation is the evolution 290 00:10:12,360 --> 00:10:13,920 of the software defined parameter. 291 00:10:13,920 --> 00:10:15,920 In the old world, we segmented networks using 292 00:10:15,920 --> 00:10:17,320 VLANs and subnets. 293 00:10:17,320 --> 00:10:18,880 If you wanted to isolate a database, 294 00:10:18,880 --> 00:10:21,280 you put it in a different subnet and managed it 295 00:10:21,280 --> 00:10:23,080 with a network security group. 296 00:10:23,080 --> 00:10:25,400 But that approach is blind to the modern reality 297 00:10:25,400 --> 00:10:26,480 of lateral movement. 298 00:10:26,480 --> 00:10:29,120 Network-level controls only care about the IP address. 299 00:10:29,120 --> 00:10:30,760 They don't care about the workload. 300 00:10:30,760 --> 00:10:33,480 If an attacker jumps the fence into your production subnet, 301 00:10:33,480 --> 00:10:35,360 they can see every database sitting there. 302 00:10:35,360 --> 00:10:36,240 They can scan ports. 303 00:10:36,240 --> 00:10:37,840 They can map the environment. 304 00:10:37,840 --> 00:10:39,320 This is where East West traffic becomes 305 00:10:39,320 --> 00:10:40,400 the primary battleground. 306 00:10:40,400 --> 00:10:43,640 In 2026, the battle isn't one at the edge of the network. 307 00:10:43,640 --> 00:10:45,320 It's one or lost inside the data center. 308 00:10:45,320 --> 00:10:48,080 We are moving away from segmenting by infrastructure. 309 00:10:48,080 --> 00:10:50,520 We are segmenting by workload identity. 310 00:10:50,520 --> 00:10:52,880 This is identity-based microsegmentation. 311 00:10:52,880 --> 00:10:54,720 Instead of a firewall rule that says 312 00:10:54,720 --> 00:10:58,000 subnet A can talk to subnet B, we use policies that say 313 00:10:58,000 --> 00:11:01,320 app service identity X can talk to SQL instance Y. 314 00:11:01,320 --> 00:11:03,080 The network path becomes irrelevant. 315 00:11:03,080 --> 00:11:05,920 The identity is the only thing that unlocks the connection. 316 00:11:05,920 --> 00:11:08,000 By using user assigned managed identities 317 00:11:08,000 --> 00:11:09,520 as your primary identities, 318 00:11:09,520 --> 00:11:12,200 you can create granular workload-specific policies. 319 00:11:12,200 --> 00:11:15,000 You can ensure that your HR applications identity 320 00:11:15,000 --> 00:11:16,720 can only see the HR database, 321 00:11:16,720 --> 00:11:18,680 even if it's sitting on the same logical server 322 00:11:18,680 --> 00:11:20,040 as the finance data. 323 00:11:20,040 --> 00:11:21,720 This level of isolation is impossible 324 00:11:21,720 --> 00:11:23,280 with traditional firewall rules, 325 00:11:23,280 --> 00:11:26,200 but implementing this requires a shift in how we deploy security. 326 00:11:26,200 --> 00:11:28,040 You cannot just turn on microsegmentation 327 00:11:28,040 --> 00:11:29,160 and hope for the best. 328 00:11:29,160 --> 00:11:31,120 If you do, you will break your applications. 329 00:11:31,120 --> 00:11:33,720 This is why we use the monitor mode principle. 330 00:11:33,720 --> 00:11:35,480 Before you enforce a single segment, 331 00:11:35,480 --> 00:11:37,280 you must baseline your SQL traffic 332 00:11:37,280 --> 00:11:39,080 for a minimum of two to four weeks. 333 00:11:39,080 --> 00:11:41,160 You need to see the legitimate traffic patterns. 334 00:11:41,160 --> 00:11:43,240 You need to identify every service account, 335 00:11:43,240 --> 00:11:45,440 every reporting tool, and every maintenance script 336 00:11:45,440 --> 00:11:46,840 that touches that database. 337 00:11:46,840 --> 00:11:48,400 During this period, the system logs 338 00:11:48,400 --> 00:11:50,560 every connection attempt that would have been blocked. 339 00:11:50,560 --> 00:11:52,240 You analyze the false positives. 340 00:11:52,240 --> 00:11:54,280 You refine the identity-based rules. 341 00:11:54,280 --> 00:11:55,960 Only when you have zero unexplained denials, 342 00:11:55,960 --> 00:11:57,280 do you move to enforcement. 343 00:11:57,280 --> 00:11:59,160 This iterative approach is what separates 344 00:11:59,160 --> 00:12:02,520 a successful zero trust migration from a production outage. 345 00:12:02,520 --> 00:12:05,080 Identity-based segmentation determines more than just 346 00:12:05,080 --> 00:12:06,040 who can connect. 347 00:12:06,040 --> 00:12:09,480 It determines exactly which SQL objects they are allowed to see. 348 00:12:09,480 --> 00:12:12,200 By binding the identity to specific database roles 349 00:12:12,200 --> 00:12:14,640 and using features like row-level security, 350 00:12:14,640 --> 00:12:17,040 you can ensure that even a successful connection 351 00:12:17,040 --> 00:12:20,400 only yields the data necessary for that specific transaction. 352 00:12:20,400 --> 00:12:23,240 This is the ultimate goal of the software defined perimeter. 353 00:12:23,240 --> 00:12:25,040 We are shrinking the perimeter until it 354 00:12:25,040 --> 00:12:27,880 wraps around a single identity and a single workload. 355 00:12:27,880 --> 00:12:29,720 The impact of this shift is massive. 356 00:12:29,720 --> 00:12:33,240 Benchmarks from 2026 show that identity-based segmentation 357 00:12:33,240 --> 00:12:35,800 cuts breach containment time by 70%. 358 00:12:35,800 --> 00:12:36,200 Why? 359 00:12:36,200 --> 00:12:38,400 Because when an identity is compromised, 360 00:12:38,400 --> 00:12:40,120 the attacker is trapped in a tiny box. 361 00:12:40,120 --> 00:12:42,280 They can't scan the network for other databases. 362 00:12:42,280 --> 00:12:43,680 They can't use the SQL connection 363 00:12:43,680 --> 00:12:45,600 to move laterally to other services. 364 00:12:45,600 --> 00:12:48,320 The identity they stole only has one valid path. 365 00:12:48,320 --> 00:12:50,400 And the moment they try to deviate from that path, 366 00:12:50,400 --> 00:12:52,280 the system flags it as an anomaly. 367 00:12:52,280 --> 00:12:55,080 We are making the environment hostile to the intruder. 368 00:12:55,080 --> 00:12:58,000 We are making every step they take a potential tripwire. 369 00:12:58,000 --> 00:12:59,840 This level of granularity is essential, 370 00:12:59,840 --> 00:13:02,280 especially when we consider the new wave of AI tools 371 00:13:02,280 --> 00:13:04,400 that are being integrated into our environments. 372 00:13:04,400 --> 00:13:06,320 AI tools don't just use data. 373 00:13:06,320 --> 00:13:07,320 They discover it. 374 00:13:07,320 --> 00:13:08,920 And if your segmentation is weak, 375 00:13:08,920 --> 00:13:11,400 they will find things you never intended for them to see. 376 00:13:11,400 --> 00:13:13,040 We need to give these tools boundaries 377 00:13:13,040 --> 00:13:14,840 because without microsegmentation, 378 00:13:14,840 --> 00:13:16,600 your AI isn't just a helper. 379 00:13:16,600 --> 00:13:19,560 It's a high speed scanner for your most sensitive secrets. 380 00:13:19,560 --> 00:13:22,400 The co-pilot multiplier, governance in the AI era, 381 00:13:22,400 --> 00:13:24,720 Microsoft co-pilot doesn't create new permissions. 382 00:13:24,720 --> 00:13:26,920 It simply accelerates your existing mistakes. 383 00:13:26,920 --> 00:13:29,000 We often think of AI as an external layer, 384 00:13:29,000 --> 00:13:30,880 something that sits on top of our data. 385 00:13:30,880 --> 00:13:32,280 But in the Azure SQL world, 386 00:13:32,280 --> 00:13:34,360 co-pilot is an engine that runs on the fuel 387 00:13:34,360 --> 00:13:35,760 of your current access model. 388 00:13:35,760 --> 00:13:38,960 If that model is leaky, co-pilot becomes a supercharged, 389 00:13:38,960 --> 00:13:41,600 discovery tool for every vulnerability you've ignored. 390 00:13:41,600 --> 00:13:44,920 It turns latent permissions sprawl into immediate searchable exposure. 391 00:13:44,920 --> 00:13:47,560 In the past, an overprivileged user might not have known 392 00:13:47,560 --> 00:13:49,320 they had access to the payroll table. 393 00:13:49,320 --> 00:13:51,080 They would have had to know the table name. 394 00:13:51,080 --> 00:13:53,720 They would have had to write a specific T-SQL query. 395 00:13:53,720 --> 00:13:55,120 The friction of the interface acted 396 00:13:55,120 --> 00:13:57,120 as a secondary accidental security layer. 397 00:13:57,120 --> 00:13:58,200 That friction is gone. 398 00:13:58,200 --> 00:14:02,360 Now that same user can simply ask a natural language question, 399 00:14:02,360 --> 00:14:04,800 show me the salary trends for the executive team. 400 00:14:04,800 --> 00:14:07,360 Co-pilot doesn't care that the user shouldn't see that data. 401 00:14:07,360 --> 00:14:09,280 It only cares that the user can see it. 402 00:14:09,280 --> 00:14:10,360 If the account has the rights, 403 00:14:10,360 --> 00:14:12,240 co-pilot will fetch the answer in seconds. 404 00:14:12,240 --> 00:14:13,960 It bypasses the need for technical knowledge 405 00:14:13,960 --> 00:14:15,360 and goes straight to the value. 406 00:14:15,360 --> 00:14:17,040 The statistics here are staggering. 407 00:14:17,040 --> 00:14:20,560 Recent risk reports show that 83% of sensitive business files 408 00:14:20,560 --> 00:14:22,640 in Azure SQL are currently overshared. 409 00:14:22,640 --> 00:14:25,440 They are sitting in tables with public or all users' access 410 00:14:25,440 --> 00:14:28,360 because someone wanted to avoid a support ticket three years ago. 411 00:14:28,360 --> 00:14:30,320 Co-pilot knows exactly where those files are. 412 00:14:30,320 --> 00:14:32,160 It has indexed the metadata. 413 00:14:32,160 --> 00:14:35,520 It understands the relationships between your schemers. 414 00:14:35,520 --> 00:14:38,000 This creates what we call the "blast radius" effect. 415 00:14:38,000 --> 00:14:40,840 A single prompt can surface full schemers and sensitive tables 416 00:14:40,840 --> 00:14:43,280 that were buried under layers of legacy documentation. 417 00:14:43,280 --> 00:14:45,640 It turns a minor oversight into a major breach. 418 00:14:45,640 --> 00:14:48,480 We have to stop treating AI governance as a separate project. 419 00:14:48,480 --> 00:14:51,080 It is a direct extension of your identity strategy. 420 00:14:51,080 --> 00:14:53,440 If you haven't audited your SQL permissions, 421 00:14:53,440 --> 00:14:57,040 deploying co-pilot is like handing an intruder a high-speed scanner. 422 00:14:57,040 --> 00:14:59,160 You are giving the AI the keys to a house 423 00:14:59,160 --> 00:15:01,280 where the internal doors are all unlocked. 424 00:15:01,280 --> 00:15:03,080 To fix this, we have to implement 425 00:15:03,080 --> 00:15:05,440 row-level security and ledger tables. 426 00:15:05,440 --> 00:15:08,040 We need to give co-pilot the boundaries it lacks by default. 427 00:15:08,040 --> 00:15:11,640 Row-level security ensures that even if the AI runs a broad query, 428 00:15:11,640 --> 00:15:15,360 it only sees the specific rows that the user is authorized to view. 429 00:15:15,360 --> 00:15:17,560 It acts as a filter at the database engine level. 430 00:15:17,560 --> 00:15:19,600 It doesn't matter how clever the prompt is. 431 00:15:19,600 --> 00:15:21,720 If the identity doesn't have the row-level right, 432 00:15:21,720 --> 00:15:23,640 the data doesn't exist for that session. 433 00:15:23,640 --> 00:15:26,440 Ledger tables add another layer of structural integrity. 434 00:15:26,440 --> 00:15:28,000 They provide a blockchain-inspired, 435 00:15:28,000 --> 00:15:31,120 tamper-proof history of every change made to your data. 436 00:15:31,120 --> 00:15:34,320 In an era where AI can generate and modify content at scale, 437 00:15:34,320 --> 00:15:36,760 knowing the exact provenance of a record is critical, 438 00:15:36,760 --> 00:15:39,040 you need to be able to prove that a specific value 439 00:15:39,040 --> 00:15:41,440 hasn't been hallucinated or manipulated. 440 00:15:41,440 --> 00:15:43,640 The ledger provides that verifiable truth, 441 00:15:43,640 --> 00:15:45,600 but these tools are only effective if they 442 00:15:45,600 --> 00:15:47,840 are part of a broader governance framework. 443 00:15:47,840 --> 00:15:51,240 You must baseline your permissions before the AI starts discovery. 444 00:15:51,240 --> 00:15:54,400 Use Microsoft Per View to map your sensitive SQL objects. 445 00:15:54,400 --> 00:15:56,760 Identify the crown jewels of your data estate, 446 00:15:56,760 --> 00:15:59,920 and then apply the microsegmentation principles we discussed. 447 00:15:59,920 --> 00:16:02,800 If a user doesn't need to see financial data for their job, 448 00:16:02,800 --> 00:16:05,440 their identity should be blocked from that segment entirely. 449 00:16:05,440 --> 00:16:07,360 This prevents co-pilot from even acknowledging 450 00:16:07,360 --> 00:16:09,640 the existence of those tables during a session. 451 00:16:09,640 --> 00:16:12,760 We are moving into an era where good enough security is a liability. 452 00:16:12,760 --> 00:16:15,080 The speed of AI demands a level of precision 453 00:16:15,080 --> 00:16:16,960 that legacy models can't provide. 454 00:16:16,960 --> 00:16:19,960 If you rely on the user to do the right thing, you've already lost. 455 00:16:19,960 --> 00:16:21,400 The system must enforce the right thing 456 00:16:21,400 --> 00:16:22,920 through structural constraints, 457 00:16:22,920 --> 00:16:26,120 because in the AI era, visibility is the greatest risk, 458 00:16:26,120 --> 00:16:27,680 and the only way to manage that risk 459 00:16:27,680 --> 00:16:30,320 is through granular identity-based control. 460 00:16:30,320 --> 00:16:33,440 The 2026 audit trap and compliance reality. 461 00:16:33,440 --> 00:16:36,120 All of these technical shifts serve one master, 462 00:16:36,120 --> 00:16:38,560 the new aggressive regulatory landscape. 463 00:16:38,560 --> 00:16:42,520 Dora 2026 has changed the game for every architect working in the cloud. 464 00:16:42,520 --> 00:16:44,840 The days of relying on vendor attestations are over. 465 00:16:44,840 --> 00:16:47,800 Regulators no longer care that Microsoft has a SOC tool reported. 466 00:16:47,800 --> 00:16:50,920 They want to see how you are using the platform to ensure resilience. 467 00:16:50,920 --> 00:16:52,920 They want regulator-friendly evidence. 468 00:16:52,920 --> 00:16:55,600 This means your own test logs, your own exit runbooks, 469 00:16:55,600 --> 00:16:57,600 and your own verifiable audit trails. 470 00:16:57,600 --> 00:17:00,400 If you can't prove exactly who accessed a specific database record 471 00:17:00,400 --> 00:17:03,640 within 30 seconds of an inquiry, you've already failed the audit. 472 00:17:03,640 --> 00:17:06,600 The burden of proof has shifted from the provider to the consumer. 473 00:17:06,600 --> 00:17:08,440 But there is a technical trap waiting for you 474 00:17:08,440 --> 00:17:11,680 in the Azure portal, the 4,000 character truncation trap. 475 00:17:11,680 --> 00:17:13,880 Azure SQL audit logs have a physical limit. 476 00:17:13,880 --> 00:17:15,800 If your SQL statements or data sensitivity 477 00:17:15,800 --> 00:17:17,760 info exceeds 4,000 characters, 478 00:17:17,760 --> 00:17:20,000 the log literally cuts off the evidence. 479 00:17:20,000 --> 00:17:21,640 The most critical part of the query, 480 00:17:21,640 --> 00:17:23,400 the part that proves what was accessed, 481 00:17:23,400 --> 00:17:25,040 could be missing from your history. 482 00:17:25,040 --> 00:17:27,000 If an auditor sees truncated logs, 483 00:17:27,000 --> 00:17:28,800 they don't see a technical limitation. 484 00:17:28,800 --> 00:17:31,200 They see a compliance gap, they see a lack of oversight. 485 00:17:31,200 --> 00:17:34,280 To avoid this, you must move toward database-level auditing. 486 00:17:34,280 --> 00:17:37,600 Server-level auditing is too noisy and too slow for modern requirements. 487 00:17:37,600 --> 00:17:39,520 It creates a mountain of data that is impossible 488 00:17:39,520 --> 00:17:41,560 to search during an active investigation. 489 00:17:41,560 --> 00:17:43,440 Database-level auditing allows you to focus 490 00:17:43,440 --> 00:17:45,600 on the specific workloads that matter. 491 00:17:45,600 --> 00:17:47,440 It gives you the granularity to meet the door 492 00:17:47,440 --> 00:17:49,400 requirements for critical functions. 493 00:17:49,400 --> 00:17:51,000 Compliance isn't a checkbox anymore. 494 00:17:51,000 --> 00:17:53,920 It is a continuous verifiable, operating posture. 495 00:17:53,920 --> 00:17:55,280 You need to be able to demonstrate 496 00:17:55,280 --> 00:17:57,200 that your identity-based microsegmentation 497 00:17:57,200 --> 00:17:58,600 is working in real time. 498 00:17:58,600 --> 00:18:01,760 You need to show that your JT Windows are being enforced. 499 00:18:01,760 --> 00:18:03,760 And you need to prove that your managed identities 500 00:18:03,760 --> 00:18:06,360 are the only ones touching your production data. 501 00:18:06,360 --> 00:18:08,880 This requires a shift in how we think about logs. 502 00:18:08,880 --> 00:18:10,480 They aren't just for troubleshooting. 503 00:18:10,480 --> 00:18:12,160 They are your defense in a regulatory world 504 00:18:12,160 --> 00:18:15,000 that is increasingly hostile to trust-me security. 505 00:18:15,000 --> 00:18:17,280 The 2026 audit isn't a test of your tools. 506 00:18:17,280 --> 00:18:18,520 It is a test of your model. 507 00:18:18,520 --> 00:18:20,280 If your model is built on static IPs 508 00:18:20,280 --> 00:18:22,600 and shared secrets, no amount of logging will save you. 509 00:18:22,600 --> 00:18:24,680 The evidence will simply document your failure. 510 00:18:24,680 --> 00:18:26,360 But if you've built on identity, 511 00:18:26,360 --> 00:18:28,280 the logs become your greatest asset. 512 00:18:28,280 --> 00:18:29,640 They provide the structural proof 513 00:18:29,640 --> 00:18:32,720 that your environment is resilient, segmented, and secure. 514 00:18:32,720 --> 00:18:35,520 The firewall is obsolete because trust is no longer a perimeter. 515 00:18:35,520 --> 00:18:37,440 It is a transaction. 516 00:18:37,440 --> 00:18:40,120 Your homework ordered your firewall rules today 517 00:18:40,120 --> 00:18:42,960 and identified every connection still using a static password. 518 00:18:42,960 --> 00:18:45,400 Start your transition to intra-only authentication 519 00:18:45,400 --> 00:18:48,200 and pilot jad for your high-privileged roles immediately. 520 00:18:48,200 --> 00:18:50,440 If this changed how you think about your data, follow me, 521 00:18:50,440 --> 00:18:52,040 Milcopeters, on LinkedIn. 522 00:18:52,040 --> 00:18:54,480 Leave a review for the M365FM podcast. 523 00:18:54,480 --> 00:18:57,000 It helps more architects find these structural truths. 524 00:18:57,000 --> 00:18:58,880 The legacy network model is broken. 525 00:18:58,880 --> 00:19:01,640 It is time for you to rebuild on identity. 526 00:19:01,640 --> 00:19:04,480 Every query must be verified, every access must be earned, 527 00:19:04,480 --> 00:19:06,400 and every secret must be eliminated. 528 00:19:06,400 --> 00:19:09,080 Stop building walls, start building verifiable trust. 529 00:19:09,080 --> 00:19:11,920 This is the future of Azure SQL Security.