Apple Podcasts
Spotify
Youtube Music
Spreaker
Podchaser
Amazon Music
Your Azure SQL firewall is no longer protecting your data. It is protecting outdated assumptions. In this episode of the M365FM Podcast, we expose the structural collapse of perimeter-based security and explain why traditional Azure SQL firewall strategies are failing in today’s AI-driven threat landscape. Most organizations still believe that static IP rules, trusted VNets, and service principals create a secure boundary around their databases. In reality, those controls were designed for a world that no longer exists. Attackers are no longer trying to break through the perimeter. They are bypassing it entirely through compromised identities, leaked credentials, over-privileged service principals, and lateral movement inside trusted environments. The network itself is no longer the source of trust. Identity is. We break down why “set and forget” firewall rules are becoming one of the biggest causes of modern compliance failures and security breaches in Azure SQL environments. From the dangerous misconception behind the “Allow Azure Services” checkbox to the growing risks of standing privileges and credential sprawl, this episode reveals why static security models are fundamentally incompatible with Zero Trust architecture in 2026. If your production databases still rely on connection strings, long-lived secrets, or unrestricted service principals, your environment may already contain invisible attack paths waiting to be exploited.
THE COLLAPSE OF THE TRADITIONAL SECURITY PERIMETER
For decades, infrastructure security depended on one core assumption: if traffic came from the “right” network, it could be trusted. Firewalls, IP whitelists, VPNs, and subnet isolation became the foundation of enterprise architecture. But cloud computing destroyed that model. Modern workloads move dynamically across regions, services, pipelines, APIs, containers, and AI-driven automation layers. Applications no longer operate from fixed locations, and users no longer access systems from predictable networks. Yet many Azure SQL deployments are still protected by security models built for a 1990s data center. We explain why static IP-based trust is now a liability instead of a defense mechanism, and how attackers exploit over-trusted network paths to move laterally through cloud environments without triggering traditional perimeter alerts. This episode also examines the dangerous illusion created by Azure SQL firewall rules and why network-level trust becomes meaningless the moment a privileged identity is compromised.
WHY SERVICE PRINCIPALS HAVE BECOME A SECURITY CRISIS
Service principals were supposed to enable secure automation. Instead, they created one of the largest unmanaged attack surfaces in Azure. We dive deep into the hidden risks of non-human identities, leaked client secrets, connection strings, orphaned credentials, and persistent standing privileges that never expire. With millions of secrets leaked publicly through GitHub repositories and CI/CD pipelines, attackers increasingly target service principals because they provide silent, persistent access that often bypasses human security controls entirely. This episode explores:
- Why long-lived credentials are structurally insecure
- How orphaned service principals survive long after applications are retired
- Why password rotation alone cannot solve identity sprawl
- How attackers weaponize leaked database secrets for persistent access
- Why Managed Identities are rapidly replacing traditional service principal models
MANAGED IDENTITIES AND THE MOVE TO PASSWORDLESS SECURITY
The future of Azure SQL security is not stronger passwords. It is removing passwords from the equation entirely. We break down how Managed Identities fundamentally change the security model for Azure workloads by binding identity directly to the workload itself instead of relying on manually managed secrets. Unlike traditional service principals, Managed Identities eliminate secret storage, reduce operational overhead, and drastically limit credential theft scenarios. You’ll learn:
- The difference between System-Assigned and User-Assigned Managed Identities
- Why short-lived identity tokens reduce blast radius
- How Managed Identities prevent credential reuse from external systems
- Why passwordless architectures improve both resilience and security
- How Azure handles token rotation automatically behind the scenes
JUST-IN-TIME ACCESS AND THE DEATH OF STANDING PRIVILEGES
Permanent access is one of the greatest security failures in modern cloud environments. Most Azure SQL environments still grant administrators, developers, and automation pipelines continuous high-level permissions even when they are not actively performing privileged tasks. This creates massive windows of opportunity for attackers. In this episode, we explore how Just-In-Time (JIT) access using Microsoft Entra Privileged Identity Management (PIM) dramatically reduces attack surface by limiting privilege activation to approved, time-bound sessions. We explain:
- Why standing privileges enable lateral movement
- How PIM-enabled groups simplify Azure SQL access governance
- Why MFA and approval workflows are essential for privileged access
- How JIT reduces exposure windows from years to hours
- Why temporary elevation is becoming mandatory under Zero Trust principles
IDENTITY-BASED MICRO-SEGMENTATION
Traditional network segmentation is no longer enough. Modern attackers operate inside trusted environments, moving east-west across workloads after compromising a single identity or endpoint. This episode explores why micro-segmentation based on identity—not IP address—is becoming the new foundation of secure Azure SQL architecture. We discuss:
- Why VLANs and subnet isolation fail against identity compromise
- How workload identities create granular trust boundaries
- The role of User-Assigned Managed Identities in workload isolation
- Why Row-Level Security matters in Zero Trust environments
- How identity-aware segmentation limits breach propagation
THE COPILOT MULTIPLIER: AI AND DATA EXPOSURE RISKS
Microsoft Copilot does not create new permissions. It amplifies the permissions you already failed to control. One of the biggest security risks in the AI era is not the AI itself—it is the underlying access model feeding it. Over-permissioned Azure SQL environments become dramatically more dangerous when AI tools can instantly discover, summarize, and expose sensitive data through natural language prompts. This episode explores:
- Why AI removes the “technical friction” that once protected hidden data
- How Copilot accelerates permission sprawl into searchable exposure
- Why overshared SQL tables create massive AI governance risks
- The role of Row-Level Security and Ledger Tables in AI governance
- How Microsoft Purview helps classify sensitive SQL workloads
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
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.
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.