Compliance as Code: The Architect’s Blueprint for Automated Trust

1
00:00:00,000 --> 00:00:02,360
Your compliance program has a document, probably several,

2
00:00:02,360 --> 00:00:04,760
a policy PDF someone approved 18 months ago,

3
00:00:04,760 --> 00:00:07,280
a quarterly access review that lives in a spreadsheet,

4
00:00:07,280 --> 00:00:09,280
a change advisory board that meets on Thursdays

5
00:00:09,280 --> 00:00:11,060
and moves at the speed of bureaucracy,

6
00:00:11,060 --> 00:00:12,920
and somewhere in your environment right now.

7
00:00:12,920 --> 00:00:14,520
A storage account is public,

8
00:00:14,520 --> 00:00:17,000
a service principle with tenant-wide graph permissions

9
00:00:17,000 --> 00:00:18,840
hasn't been rotated in two years,

10
00:00:18,840 --> 00:00:20,960
and a developer spun up a resource last Tuesday

11
00:00:20,960 --> 00:00:22,920
that violates six standards you care about.

12
00:00:22,920 --> 00:00:25,640
Nobody flagged it, the audit won't catch it until Q3.

13
00:00:25,640 --> 00:00:28,160
That's not a tools problem, that's a model problem.

14
00:00:28,160 --> 00:00:29,960
You're running a manual governance process

15
00:00:29,960 --> 00:00:31,280
in an automated world,

16
00:00:31,280 --> 00:00:33,840
the gap between governance speed and deployment speed.

17
00:00:33,840 --> 00:00:35,600
That gap is exactly where breaches live.

18
00:00:35,600 --> 00:00:37,080
It's where drift accumulates,

19
00:00:37,080 --> 00:00:39,880
it's where your next audit finding is already being written.

20
00:00:39,880 --> 00:00:42,440
Most teams treat developer speed and security control

21
00:00:42,440 --> 00:00:43,400
as a trade-off.

22
00:00:43,400 --> 00:00:44,760
Move fast or stay secure.

23
00:00:44,760 --> 00:00:46,360
Pick one, that framing is wrong,

24
00:00:46,360 --> 00:00:49,080
and it's costing organizations enormous amounts of time,

25
00:00:49,080 --> 00:00:50,200
money and exposure.

26
00:00:50,200 --> 00:00:51,360
What we're covering today,

27
00:00:51,360 --> 00:00:53,320
dismantles that assumption completely.

28
00:00:53,320 --> 00:00:54,880
In the next 100 minutes,

29
00:00:54,880 --> 00:00:56,840
you're getting the full architectural blueprint

30
00:00:56,840 --> 00:01:00,840
for making compliance, automatic, auditable and developer friendly.

31
00:01:00,840 --> 00:01:02,240
At the same time, as your policy,

32
00:01:02,240 --> 00:01:03,320
our back at scale,

33
00:01:03,320 --> 00:01:05,000
managed identities, key vault,

34
00:01:05,000 --> 00:01:07,160
and variety governance were going deep on all of it.

35
00:01:07,160 --> 00:01:09,080
If you're not subscribed, do that now.

36
00:01:09,080 --> 00:01:11,280
This is the kind of content we build for architects

37
00:01:11,280 --> 00:01:14,360
and security engineers who want the real technical depth,

38
00:01:14,360 --> 00:01:15,720
not the surface level overview.

39
00:01:15,720 --> 00:01:16,800
Let's get into it.

40
00:01:16,800 --> 00:01:19,080
Why manual governance always fails?

41
00:01:19,080 --> 00:01:20,520
The old model looks like this.

42
00:01:20,520 --> 00:01:22,400
A developer needs access, they open a ticket,

43
00:01:22,400 --> 00:01:23,720
the ticket goes to an approver.

44
00:01:23,720 --> 00:01:24,840
The approver is busy,

45
00:01:24,840 --> 00:01:26,560
three days later the access is granted,

46
00:01:26,560 --> 00:01:28,520
probably at a higher permission level than needed,

47
00:01:28,520 --> 00:01:29,880
it's faster to give contributor

48
00:01:29,880 --> 00:01:31,760
than to figure out the exact right scope.

49
00:01:31,760 --> 00:01:33,320
The developer finishes the project,

50
00:01:33,320 --> 00:01:35,360
the access stays, nobody removes it.

51
00:01:35,360 --> 00:01:37,120
Multiply that by 200 developers,

52
00:01:37,120 --> 00:01:39,840
40 subscriptions and 18 months of project churn.

53
00:01:39,840 --> 00:01:41,800
What you get isn't a governance program,

54
00:01:41,800 --> 00:01:43,080
it's the appearance of one.

55
00:01:43,080 --> 00:01:44,280
This is the structural failure

56
00:01:44,280 --> 00:01:45,760
at the heart of manual governance.

57
00:01:45,760 --> 00:01:46,960
Humans are the bottleneck,

58
00:01:46,960 --> 00:01:48,280
the single point of failure,

59
00:01:48,280 --> 00:01:51,360
and the source of inconsistency, all at once.

60
00:01:51,360 --> 00:01:53,360
Change advisory boards were designed for a world

61
00:01:53,360 --> 00:01:54,960
where deployments happened weekly,

62
00:01:54,960 --> 00:01:56,760
and infrastructure changed slowly.

63
00:01:56,760 --> 00:01:59,600
In that world, a human reviewing every change made sense.

64
00:01:59,600 --> 00:02:01,560
But in a world where a CI/CD pipeline

65
00:02:01,560 --> 00:02:03,600
can deploy infrastructure in four minutes,

66
00:02:03,600 --> 00:02:05,040
the math doesn't work anymore.

67
00:02:05,040 --> 00:02:06,480
Governance speed is measured in days,

68
00:02:06,480 --> 00:02:08,440
deployment speed is measured in minutes,

69
00:02:08,440 --> 00:02:11,000
that gap doesn't just create friction, it creates risk.

70
00:02:11,000 --> 00:02:13,920
When governance can't keep up with deployment,

71
00:02:13,920 --> 00:02:16,200
teams root around it, they find exceptions,

72
00:02:16,200 --> 00:02:17,600
they create shadow IT,

73
00:02:17,600 --> 00:02:19,080
they grant themselves standing access

74
00:02:19,080 --> 00:02:21,640
because waiting for approval breaks their sprint.

75
00:02:21,640 --> 00:02:24,000
Every workaround is a small act of pragmatism

76
00:02:24,000 --> 00:02:26,520
that in aggregate produces an environment

77
00:02:26,520 --> 00:02:27,840
nobody fully understands.

78
00:02:27,840 --> 00:02:29,640
The real cost shows up in three places.

79
00:02:29,640 --> 00:02:32,080
Configuration drift, resources that were compliant

80
00:02:32,080 --> 00:02:34,160
at deployment and drifted into non-compliance

81
00:02:34,160 --> 00:02:35,760
over months with no one noticing.

82
00:02:35,760 --> 00:02:37,640
Shadow IT workloads and integrations

83
00:02:37,640 --> 00:02:40,000
that exist completely outside the governance perimeter

84
00:02:40,000 --> 00:02:42,440
because the govern path was too slow to be usable

85
00:02:42,440 --> 00:02:44,640
and often service principles.

86
00:02:44,640 --> 00:02:46,600
Application identities with broad permissions

87
00:02:46,600 --> 00:02:47,800
that outlived their projects,

88
00:02:47,800 --> 00:02:49,520
sitting undetected in your tenant

89
00:02:49,520 --> 00:02:51,640
with secrets that haven't rotated in years.

90
00:02:51,640 --> 00:02:53,640
Here's the number that should stop you cold.

91
00:02:53,640 --> 00:02:56,000
According to research across large organizations,

92
00:02:56,000 --> 00:02:59,000
nearly half have suffered a Microsoft 365 Security

93
00:02:59,000 --> 00:03:01,400
or Compliance Incident caused by misconfiguration,

94
00:03:01,400 --> 00:03:04,240
not sophisticated attacks, not nation state threat actors,

95
00:03:04,240 --> 00:03:06,080
misconfiguration.

96
00:03:06,080 --> 00:03:08,400
The environment drifted from the intended state,

97
00:03:08,400 --> 00:03:09,480
nobody courted,

98
00:03:09,480 --> 00:03:11,920
and eventually someone exploited it or an auditor founded.

99
00:03:11,920 --> 00:03:13,280
This is the audit theater problem.

100
00:03:13,280 --> 00:03:15,600
Policies exist on paper, they're reviewed annually,

101
00:03:15,600 --> 00:03:18,600
they're signed and filed, but they're never technically enforced.

102
00:03:18,600 --> 00:03:21,040
A policy that lives only in a document is not a control,

103
00:03:21,040 --> 00:03:21,920
it's a wish.

104
00:03:21,920 --> 00:03:24,960
And here's the insight that reframes the entire conversation.

105
00:03:24,960 --> 00:03:26,520
The problem isn't that people are careless,

106
00:03:26,520 --> 00:03:28,480
most security teams are deeply committed

107
00:03:28,480 --> 00:03:31,480
and most developers genuinely want to do the right thing.

108
00:03:31,480 --> 00:03:34,440
The problem is that manual systems structurally cannot scale.

109
00:03:34,440 --> 00:03:37,200
When you depend on humans to catch every misconfiguration,

110
00:03:37,200 --> 00:03:39,760
review every access request and enforce every standard.

111
00:03:39,760 --> 00:03:42,320
You've already lost, not because of bad intentions,

112
00:03:42,320 --> 00:03:43,520
because of physics.

113
00:03:43,520 --> 00:03:45,160
There aren't enough hours enough reviewers

114
00:03:45,160 --> 00:03:46,880
or enough attention cycles to keep pace

115
00:03:46,880 --> 00:03:48,560
with modern deployment velocity.

116
00:03:48,560 --> 00:03:50,240
The answer isn't more humans in the loop,

117
00:03:50,240 --> 00:03:53,000
the answer is removing humans from the enforcement loop entirely

118
00:03:53,000 --> 00:03:55,240
and putting them where they actually add value

119
00:03:55,240 --> 00:03:57,400
in the design of the system that enforces itself.

120
00:03:57,400 --> 00:03:58,880
That's what compliance as code is.

121
00:03:58,880 --> 00:04:00,520
And it starts with understanding a distinction

122
00:04:00,520 --> 00:04:02,400
most architects get wrong.

123
00:04:02,400 --> 00:04:05,120
The foundational confusion, RBAC versus policy.

124
00:04:05,120 --> 00:04:06,680
Here is the architectural mistake I see

125
00:04:06,680 --> 00:04:08,960
in almost every Azure environment I review.

126
00:04:08,960 --> 00:04:10,760
The security team wants to stop developers

127
00:04:10,760 --> 00:04:12,600
from deploying public storage accounts,

128
00:04:12,600 --> 00:04:14,360
so they tighten the RBAC model.

129
00:04:14,360 --> 00:04:16,800
They strip permissions, they remove the contributor role

130
00:04:16,800 --> 00:04:18,160
from specific groups,

131
00:04:18,160 --> 00:04:19,880
and they think the problem is solved.

132
00:04:19,880 --> 00:04:22,240
Three weeks later, someone with the right role assignment

133
00:04:22,240 --> 00:04:24,200
deploys a public storage account anyway,

134
00:04:24,200 --> 00:04:26,720
because RBAC never governed that, RBAC never could.

135
00:04:26,720 --> 00:04:28,320
This is the foundational confusion.

136
00:04:28,320 --> 00:04:30,960
RBAC and Azure policy are not substitutes for each other.

137
00:04:30,960 --> 00:04:33,720
They don't overlap, they answer completely different questions.

138
00:04:33,720 --> 00:04:36,320
And conflating them is how you end up with a governance model

139
00:04:36,320 --> 00:04:38,960
that looks great on paper, but fails in production.

140
00:04:38,960 --> 00:04:41,240
RBAC answers one question, who can act?

141
00:04:41,240 --> 00:04:43,280
It is identity-centric authorization.

142
00:04:43,280 --> 00:04:46,080
You are assigning a principle, a user, a group,

143
00:04:46,080 --> 00:04:48,080
or a managed identity.

144
00:04:48,080 --> 00:04:50,240
Permission to perform actions on resources.

145
00:04:50,240 --> 00:04:52,760
When you give someone the contributor role on a subscription,

146
00:04:52,760 --> 00:04:55,120
you are saying this identity is authorized

147
00:04:55,120 --> 00:04:58,880
to create and delete resources in this scope, that is it.

148
00:04:58,880 --> 00:05:02,240
RBAC draws the boundary around what identities are allowed to do.

149
00:05:02,240 --> 00:05:04,920
Azure policy answers a completely different question.

150
00:05:04,920 --> 00:05:06,480
What is allowed to exist?

151
00:05:06,480 --> 00:05:08,000
It is resource-centric enforcement.

152
00:05:08,000 --> 00:05:11,120
You are defining the state your environment must conform to.

153
00:05:11,120 --> 00:05:13,480
And the policy engine evaluates every resource

154
00:05:13,480 --> 00:05:15,320
against that definition at deployment time

155
00:05:15,320 --> 00:05:16,960
and continuously afterward.

156
00:05:16,960 --> 00:05:19,440
When you assign a policy that denies storage accounts

157
00:05:19,440 --> 00:05:21,560
with public network access, you are saying

158
00:05:21,560 --> 00:05:23,560
this configuration is not permitted.

159
00:05:23,560 --> 00:05:25,640
Regardless of who is asking, notice what that means,

160
00:05:25,640 --> 00:05:28,560
a user with contributor rights, fully authorized by RBAC,

161
00:05:28,560 --> 00:05:30,640
can attempt to deploy a public storage account.

162
00:05:30,640 --> 00:05:34,080
RBAC said yes to that user, but policy says no to that resource.

163
00:05:34,080 --> 00:05:35,080
The deployment fails.

164
00:05:35,080 --> 00:05:37,240
It fails not because the user lacked permission,

165
00:05:37,240 --> 00:05:41,040
but because the resource configuration violated the defined state.

166
00:05:41,040 --> 00:05:42,280
This is the layered model.

167
00:05:42,280 --> 00:05:45,360
RBAC governs the actor, policy governs the environment.

168
00:05:45,360 --> 00:05:47,320
One without the other leaves you exposed in ways

169
00:05:47,320 --> 00:05:49,080
you won't see until something breaks.

170
00:05:49,080 --> 00:05:50,720
There is a default behavior difference here

171
00:05:50,720 --> 00:05:52,400
that matters for your architecture.

172
00:05:52,400 --> 00:05:54,000
RBAC defaults to deny.

173
00:05:54,000 --> 00:05:55,960
If you haven't explicitly granted a permission,

174
00:05:55,960 --> 00:05:56,800
the answer is no.

175
00:05:56,800 --> 00:05:59,280
That is why least privilege RBAC is achievable.

176
00:05:59,280 --> 00:06:00,760
You are working from a closed system

177
00:06:00,760 --> 00:06:02,400
and opening specific doors.

178
00:06:02,400 --> 00:06:03,840
Azure policy defaults to allow.

179
00:06:03,840 --> 00:06:05,760
If you haven't explicitly restricted something,

180
00:06:05,760 --> 00:06:07,520
any compliant deployment goes through,

181
00:06:07,520 --> 00:06:09,360
that is why most environments drift

182
00:06:09,360 --> 00:06:11,760
because the absence of a policy isn't a guardrail.

183
00:06:11,760 --> 00:06:12,680
It's an open field.

184
00:06:12,680 --> 00:06:15,600
Understanding that difference changes how you design governance.

185
00:06:15,600 --> 00:06:17,200
RBAC titans what identities can do.

186
00:06:17,200 --> 00:06:19,400
Policy titans what the environment can contain.

187
00:06:19,400 --> 00:06:21,400
You need both moving in the same direction.

188
00:06:21,400 --> 00:06:22,960
Applied at the right layers.

189
00:06:22,960 --> 00:06:24,480
Serving their distinct purposes.

190
00:06:24,480 --> 00:06:26,400
Where does this get complex in the real world?

191
00:06:26,400 --> 00:06:28,280
Key Vault is the clearest example.

192
00:06:28,280 --> 00:06:30,600
Microsoft's current guidance is explicit.

193
00:06:30,600 --> 00:06:33,400
Use Azure RBAC for key vault data plane authorization,

194
00:06:33,400 --> 00:06:35,080
not legacy access policies.

195
00:06:35,080 --> 00:06:36,720
That is an RBAC decision controlling

196
00:06:36,720 --> 00:06:39,280
which identities can read secrets or manage keys.

197
00:06:39,280 --> 00:06:40,960
But whether a key vault is allowed to exist

198
00:06:40,960 --> 00:06:42,320
without soft delete enabled

199
00:06:42,320 --> 00:06:45,240
or without private endpoints, that is a policy decision.

200
00:06:45,240 --> 00:06:47,480
The identity governance and the resource governance work

201
00:06:47,480 --> 00:06:49,600
at different layers on the same service.

202
00:06:49,600 --> 00:06:51,680
Organizations that try to solve resource problems

203
00:06:51,680 --> 00:06:53,280
with RBAC end up with roles brawl.

204
00:06:53,280 --> 00:06:54,920
They create complex custom roles

205
00:06:54,920 --> 00:06:57,200
trying to prevent specific configurations

206
00:06:57,200 --> 00:06:59,800
when what they actually needed was a policy definition.

207
00:06:59,800 --> 00:07:02,240
And organizations that try to replace access control

208
00:07:02,240 --> 00:07:03,960
with policy end up confused

209
00:07:03,960 --> 00:07:06,360
when policy doesn't stop an authorized user

210
00:07:06,360 --> 00:07:08,480
from doing something they shouldn't.

211
00:07:08,480 --> 00:07:09,960
The mental model that clears this up,

212
00:07:09,960 --> 00:07:12,680
RBAC is the authorization layer for the actor,

213
00:07:12,680 --> 00:07:15,120
policies the compliance layer for the environment,

214
00:07:15,120 --> 00:07:16,480
neither replaces the other,

215
00:07:16,480 --> 00:07:18,920
together they form the two fundamental axes

216
00:07:18,920 --> 00:07:20,240
of Azure governance.

217
00:07:20,240 --> 00:07:21,640
And everything we build on top of them

218
00:07:21,640 --> 00:07:23,640
depends on keeping that distinction clear.

219
00:07:23,640 --> 00:07:24,800
Once you have that foundation,

220
00:07:24,800 --> 00:07:26,480
you can start thinking about governance

221
00:07:26,480 --> 00:07:27,880
as a system with structure

222
00:07:27,880 --> 00:07:30,400
and that structure has a specific shape.

223
00:07:30,400 --> 00:07:32,920
The governance stack layers that actually work.

224
00:07:32,920 --> 00:07:34,720
So you have separated the two tools,

225
00:07:34,720 --> 00:07:36,960
RBAC for the actor, policy for the environment.

226
00:07:36,960 --> 00:07:39,680
Now the question is how they fit into a broader architecture.

227
00:07:39,680 --> 00:07:41,640
Because neither one operates in isolation,

228
00:07:41,640 --> 00:07:43,720
governance at scale isn't a single control,

229
00:07:43,720 --> 00:07:45,720
it is a stack and each layer in that stack

230
00:07:45,720 --> 00:07:47,280
answers a different question

231
00:07:47,280 --> 00:07:49,200
that the layer above it can't.

232
00:07:49,200 --> 00:07:51,480
Start at the bottom, identity governance,

233
00:07:51,480 --> 00:07:53,160
who are the principles in your environment,

234
00:07:53,160 --> 00:07:54,520
how did they get their access

235
00:07:54,520 --> 00:07:55,960
and is that access still appropriate?

236
00:07:55,960 --> 00:07:57,800
This is EntraID governance territory,

237
00:07:57,800 --> 00:08:00,400
life cycle workflows, access reviews.

238
00:08:00,400 --> 00:08:02,880
It is the layer that keeps the identity model coherent

239
00:08:02,880 --> 00:08:05,960
over time even as people join, move and leave.

240
00:08:05,960 --> 00:08:08,560
Above that sits authorization RBAC.

241
00:08:08,560 --> 00:08:11,480
The layer that defines what each principle is permitted to do

242
00:08:11,480 --> 00:08:13,880
at what scope and under what conditions.

243
00:08:13,880 --> 00:08:15,560
This layer translates the identity model

244
00:08:15,560 --> 00:08:18,000
into actual permissions across your Azure estate.

245
00:08:18,000 --> 00:08:21,080
Above that sits policy guardrails, Azure policy.

246
00:08:21,080 --> 00:08:22,960
The layer that defines what the environment is allowed

247
00:08:22,960 --> 00:08:25,080
to contain independent of who is asking.

248
00:08:25,080 --> 00:08:27,120
This is where you enforce configuration standards

249
00:08:27,120 --> 00:08:29,200
and security baselines at the resource level.

250
00:08:29,200 --> 00:08:31,760
Above that sit resource locks, an narrower tool.

251
00:08:31,760 --> 00:08:34,200
But critical for protecting foundational infrastructure

252
00:08:34,200 --> 00:08:36,600
from accidental deletion, your hub network,

253
00:08:36,600 --> 00:08:37,960
your central logging workspace,

254
00:08:37,960 --> 00:08:39,360
your key vault in production.

255
00:08:39,360 --> 00:08:41,040
Locks aren't governance for everything.

256
00:08:41,040 --> 00:08:42,840
They are a last line of defense for the things

257
00:08:42,840 --> 00:08:45,640
that can't be recreated from a pipeline in a hurry

258
00:08:45,640 --> 00:08:47,440
and sitting across all of it is monitoring,

259
00:08:47,440 --> 00:08:48,600
not as a final step,

260
00:08:48,600 --> 00:08:50,960
but as a continuous thread running through every layer.

261
00:08:50,960 --> 00:08:52,840
Because a governance stack without observability

262
00:08:52,840 --> 00:08:54,760
is just hope with better documentation,

263
00:08:54,760 --> 00:08:56,680
each layer handles something the others can't.

264
00:08:56,680 --> 00:08:58,240
Identity governance can't prevent

265
00:08:58,240 --> 00:09:00,040
a misconfigured storage account.

266
00:09:00,040 --> 00:09:02,960
Policy can't recertify access that is no longer needed.

267
00:09:02,960 --> 00:09:05,400
RBAC can't tell you when your key vault configuration

268
00:09:05,400 --> 00:09:06,680
drifts from baseline,

269
00:09:06,680 --> 00:09:08,240
the power is in the combination,

270
00:09:08,240 --> 00:09:10,960
a system where each layer covers the gaps the others leave.

271
00:09:10,960 --> 00:09:13,360
The structural foundation that makes the stack coherent

272
00:09:13,360 --> 00:09:15,360
is the management group hierarchy.

273
00:09:15,360 --> 00:09:17,920
Management groups are how Azure lets you apply governance

274
00:09:17,920 --> 00:09:19,800
at scale without repeating yourself.

275
00:09:19,800 --> 00:09:21,200
You define your policy assignments

276
00:09:21,200 --> 00:09:23,480
and RBAC baselines once at the right scope,

277
00:09:23,480 --> 00:09:26,400
and they cascade down to every subscription in that hierarchy.

278
00:09:26,400 --> 00:09:28,360
The policy assigned at the root management group

279
00:09:28,360 --> 00:09:29,480
applies everywhere,

280
00:09:29,480 --> 00:09:31,440
a policy assigned to the production management group

281
00:09:31,440 --> 00:09:33,520
applies to every production subscription.

282
00:09:33,520 --> 00:09:35,000
You build the structure once

283
00:09:35,000 --> 00:09:36,480
and it shapes everything below it.

284
00:09:36,480 --> 00:09:39,400
This is where the landing zone concept becomes operational.

285
00:09:39,400 --> 00:09:41,680
A landing zone isn't just a subscription template,

286
00:09:41,680 --> 00:09:43,840
it is a pre-wired governance environment.

287
00:09:43,840 --> 00:09:45,720
When a new project subscription gets created

288
00:09:45,720 --> 00:09:47,560
inside a well-designed landing zone,

289
00:09:47,560 --> 00:09:49,920
it already has the right policy initiatives assigned

290
00:09:49,920 --> 00:09:51,840
and the right RBAC baseline in place.

291
00:09:51,840 --> 00:09:53,840
Governance isn't retrofitted after the fact.

292
00:09:53,840 --> 00:09:56,240
It is present from the first deployment, that distinction.

293
00:09:56,240 --> 00:09:58,720
Governance designed in versus governance bolted on

294
00:09:58,720 --> 00:10:00,120
has a real operational cost.

295
00:10:00,120 --> 00:10:02,080
Organizations that try to retrofit governance

296
00:10:02,080 --> 00:10:03,600
into an existing environment

297
00:10:03,600 --> 00:10:05,400
spend three to five times more effort

298
00:10:05,400 --> 00:10:07,080
than those who design it in from the start.

299
00:10:07,080 --> 00:10:08,280
You aren't just adding controls,

300
00:10:08,280 --> 00:10:10,280
you are fighting existing configurations,

301
00:10:10,280 --> 00:10:12,640
cleaning up drift and negotiating exceptions

302
00:10:12,640 --> 00:10:14,160
for things that should never have been permitted

303
00:10:14,160 --> 00:10:15,200
in the first place.

304
00:10:15,200 --> 00:10:18,080
The principle that ties this altogether is the paved road.

305
00:10:18,080 --> 00:10:20,640
When the compliant path is also the easiest path,

306
00:10:20,640 --> 00:10:22,760
developers don't need to think about governance.

307
00:10:22,760 --> 00:10:24,400
They just use the tools in front of them

308
00:10:24,400 --> 00:10:26,640
and the platform handles the rest.

309
00:10:26,640 --> 00:10:28,840
The friction that normally drives shadow IT

310
00:10:28,840 --> 00:10:30,440
and work around disappears.

311
00:10:30,440 --> 00:10:32,120
Not because you remove the standards,

312
00:10:32,120 --> 00:10:33,440
but because you made following them

313
00:10:33,440 --> 00:10:35,000
the path of least resistance.

314
00:10:35,000 --> 00:10:37,360
Everything we cover from here builds on this stack.

315
00:10:37,360 --> 00:10:39,240
Azure Policy is the enforcement engine

316
00:10:39,240 --> 00:10:40,960
at the Policy Guard Rails layer.

317
00:10:40,960 --> 00:10:43,240
Our back at scale governs the authorization layer.

318
00:10:43,240 --> 00:10:45,600
Managed identities are how workload identities

319
00:10:45,600 --> 00:10:47,040
operate inside this model

320
00:10:47,040 --> 00:10:49,320
without credentials that escape the perimeter.

321
00:10:49,320 --> 00:10:51,880
And EntraID governance is what keeps the identity layer

322
00:10:51,880 --> 00:10:54,080
coherent as the environment evolves.

323
00:10:54,080 --> 00:10:55,920
Three pillars, one architecture.

324
00:10:55,920 --> 00:10:57,560
Let's go deep on the first one.

325
00:10:57,560 --> 00:10:59,400
What Azure Policy actually does?

326
00:10:59,400 --> 00:11:01,000
Azure Policy isn't a firewall,

327
00:11:01,000 --> 00:11:02,440
it isn't a permission boundary.

328
00:11:02,440 --> 00:11:04,360
Think of it as a continuous evaluation engine,

329
00:11:04,360 --> 00:11:06,240
a referee that watches every single resource

330
00:11:06,240 --> 00:11:08,320
in your environment, it compares what it sees

331
00:11:08,320 --> 00:11:10,680
against your rules and when something doesn't match,

332
00:11:10,680 --> 00:11:12,520
it takes action.

333
00:11:12,520 --> 00:11:13,960
The model works like this.

334
00:11:13,960 --> 00:11:16,120
A policy definition is just a JSON document

335
00:11:16,120 --> 00:11:18,440
describing two things, the condition to check

336
00:11:18,440 --> 00:11:19,760
and the effect to apply.

337
00:11:19,760 --> 00:11:21,440
The condition can be almost anything,

338
00:11:21,440 --> 00:11:24,560
a resource type, a tag, or a specific configuration setting.

339
00:11:24,560 --> 00:11:27,160
The effect is what happens when a resource breaks the rule.

340
00:11:27,160 --> 00:11:28,400
This is where the strategy lives.

341
00:11:28,400 --> 00:11:30,240
You'll work with five main effects

342
00:11:30,240 --> 00:11:33,360
and each one has a specific job in your governance life cycle.

343
00:11:33,360 --> 00:11:34,840
Ordered is the lightest touch.

344
00:11:34,840 --> 00:11:37,240
It marks non-compliant resources in your dashboard

345
00:11:37,240 --> 00:11:38,440
but it doesn't block anything.

346
00:11:38,440 --> 00:11:39,640
This is your visibility layer.

347
00:11:39,640 --> 00:11:42,160
You use order when you need to see what's actually running

348
00:11:42,160 --> 00:11:44,440
before you start enforcing rules against it.

349
00:11:44,440 --> 00:11:46,040
Deny is the enforcement effect.

350
00:11:46,040 --> 00:11:48,000
If a resource violates a deny policy,

351
00:11:48,000 --> 00:11:49,320
it simply doesn't get created.

352
00:11:49,320 --> 00:11:51,200
The deployment fails at the arm layer

353
00:11:51,200 --> 00:11:53,240
before the resource ever exists.

354
00:11:53,240 --> 00:11:55,040
This turns a standard into a guardrail.

355
00:11:55,040 --> 00:11:56,640
But it also creates major incidents

356
00:11:56,640 --> 00:11:59,080
if you don't understand your blast radius first.

357
00:11:59,080 --> 00:12:01,320
Modify and append are your mutation effects.

358
00:12:01,320 --> 00:12:04,640
Modify changes a resource property during creation.

359
00:12:04,640 --> 00:12:06,720
Like automatically enabling diagnostic settings

360
00:12:06,720 --> 00:12:08,640
or forcing a specific tag value,

361
00:12:08,640 --> 00:12:10,280
append adds fields to a resource

362
00:12:10,280 --> 00:12:12,000
without changing what's already there.

363
00:12:12,000 --> 00:12:14,760
These are perfect when you want resources to follow a standard

364
00:12:14,760 --> 00:12:17,160
without blocking deployments over a missing tag.

365
00:12:17,160 --> 00:12:20,400
Deploy if not exists is the most powerful tool in the kit.

366
00:12:20,400 --> 00:12:23,360
When a resource is created and a related piece is missing,

367
00:12:23,360 --> 00:12:25,800
this effect triggers a new deployment to build it.

368
00:12:25,800 --> 00:12:28,880
For example, every storage account needs a diagnostic setting

369
00:12:28,880 --> 00:12:31,240
pointing to your log analytics workspace.

370
00:12:31,240 --> 00:12:33,600
Deploy if not exists, handles that automatically.

371
00:12:33,600 --> 00:12:35,720
So your developers don't have to remember it.

372
00:12:35,720 --> 00:12:37,600
The policy engine stops being an observer

373
00:12:37,600 --> 00:12:39,600
and starts being an active participant.

374
00:12:39,600 --> 00:12:41,720
Managing these one by one gets messy fast.

375
00:12:41,720 --> 00:12:42,960
That's why we use initiatives.

376
00:12:42,960 --> 00:12:45,480
An initiative or a policy set is just a collection

377
00:12:45,480 --> 00:12:48,080
of policies grouped into one assignable object.

378
00:12:48,080 --> 00:12:51,040
Instead of assigning 30 separate rules to a management group,

379
00:12:51,040 --> 00:12:52,400
you assign one initiative.

380
00:12:52,400 --> 00:12:55,040
This is how you make frameworks like ISO 27001

381
00:12:55,040 --> 00:12:56,760
or NIST manageable.

382
00:12:56,760 --> 00:12:58,480
Microsoft provides built-in initiatives

383
00:12:58,480 --> 00:13:01,160
for CIS benchmarks, PCI DSS and HIPAA.

384
00:13:01,160 --> 00:13:03,080
You assign the initiative and every policy

385
00:13:03,080 --> 00:13:05,600
inside it activates across that scope at once.

386
00:13:05,600 --> 00:13:07,760
The scope hierarchy gives policy its reach.

387
00:13:07,760 --> 00:13:09,760
You can assign a policy at the tenant root

388
00:13:09,760 --> 00:13:11,680
and it cascades to every single subscription

389
00:13:11,680 --> 00:13:13,080
in your entire Azure estate.

390
00:13:13,080 --> 00:13:15,040
You can also target a specific management group,

391
00:13:15,040 --> 00:13:17,200
a subscription or just one resource group.

392
00:13:17,200 --> 00:13:18,680
Inheritance flows down.

393
00:13:18,680 --> 00:13:20,760
A policy at the root applies everywhere

394
00:13:20,760 --> 00:13:22,760
unless you explicitly exempt a resource.

395
00:13:22,760 --> 00:13:24,920
This inheritance is why your management group structure

396
00:13:24,920 --> 00:13:26,080
is so important.

397
00:13:26,080 --> 00:13:28,240
You set the assignment once at the right level

398
00:13:28,240 --> 00:13:30,600
and the hierarchy does the rest of the work for you.

399
00:13:30,600 --> 00:13:32,680
There is one more piece, the compliance dashboard.

400
00:13:32,680 --> 00:13:34,640
This is your live view of how well your environment

401
00:13:34,640 --> 00:13:35,760
follows your rules.

402
00:13:35,760 --> 00:13:38,320
It shows you percentages and non-compliant resources

403
00:13:38,320 --> 00:13:39,240
in real time.

404
00:13:39,240 --> 00:13:40,240
But here's the problem.

405
00:13:40,240 --> 00:13:42,280
Looking at a dashboard isn't a compliance program.

406
00:13:42,280 --> 00:13:43,440
It's just a signal.

407
00:13:43,440 --> 00:13:46,320
What you do with that signal is the actual work of governance.

408
00:13:46,320 --> 00:13:47,880
The dashboard tells you where you are

409
00:13:47,880 --> 00:13:50,880
but your remediation pipeline determines where you stay.

410
00:13:50,880 --> 00:13:52,240
Safe deployment.

411
00:13:52,240 --> 00:13:55,000
How to roll out policy without breaking production.

412
00:13:55,000 --> 00:13:57,480
Most organizations break production the same way.

413
00:13:57,480 --> 00:13:59,440
They spend weeks designing deny policies.

414
00:13:59,440 --> 00:14:00,920
They feel good about the coverage.

415
00:14:00,920 --> 00:14:03,280
They assign the initiative to the root management group.

416
00:14:03,280 --> 00:14:05,320
Flip enforcement on and go home.

417
00:14:05,320 --> 00:14:07,680
By morning, deployment pipelines are failing everywhere.

418
00:14:07,680 --> 00:14:10,240
Critical workloads can't scale.

419
00:14:10,240 --> 00:14:12,840
The security team is stuck on calls explaining why nothing

420
00:14:12,840 --> 00:14:13,680
is working.

421
00:14:13,680 --> 00:14:14,480
This isn't a guess.

422
00:14:14,480 --> 00:14:16,440
It's the most common failure pattern in enterprises,

423
00:14:16,440 --> 00:14:17,120
you know.

424
00:14:17,120 --> 00:14:19,200
And it's avoidable if you realize the deployment strategy

425
00:14:19,200 --> 00:14:21,000
matters as much as the policy design.

426
00:14:21,000 --> 00:14:23,280
The model that fixes this is thinking in rings.

427
00:14:23,280 --> 00:14:26,040
Picture your Azure estate as a series of circles.

428
00:14:26,040 --> 00:14:28,040
The outer rings are your low risk areas.

429
00:14:28,040 --> 00:14:29,920
Sandboxes and dev subscriptions.

430
00:14:29,920 --> 00:14:31,640
The inner rings are your production systems

431
00:14:31,640 --> 00:14:33,080
and regulated workloads.

432
00:14:33,080 --> 00:14:35,400
Safe deployment always moves from the outside in.

433
00:14:35,400 --> 00:14:37,000
You prove the policy in the outer rings

434
00:14:37,000 --> 00:14:38,920
before you ever let it touch production.

435
00:14:38,920 --> 00:14:42,320
But even before that, you start with enforcement mode disabled.

436
00:14:42,320 --> 00:14:44,800
This is a setting that tells the engine to scan resources

437
00:14:44,800 --> 00:14:46,120
without blocking anything.

438
00:14:46,120 --> 00:14:49,360
You get full visibility into what the policy would catch.

439
00:14:49,360 --> 00:14:51,320
But there are no consequences for the developers.

440
00:14:51,320 --> 00:14:53,480
Think of it as running in read only mode.

441
00:14:53,480 --> 00:14:54,760
You aren't flying blind.

442
00:14:54,760 --> 00:14:57,120
You're building a map before you start closing roads.

443
00:14:57,120 --> 00:15:00,120
This makes what if analysis your best tool before enforcement

444
00:15:00,120 --> 00:15:02,960
goes live, run compliance scans to model the blast radius.

445
00:15:02,960 --> 00:15:05,800
You need to know how many resources are non-compliant right now.

446
00:15:05,800 --> 00:15:08,560
You need to know which subscriptions are hit hardest.

447
00:15:08,560 --> 00:15:10,800
Answering these questions while enforcement is disabled

448
00:15:10,800 --> 00:15:11,840
costs you nothing.

449
00:15:11,840 --> 00:15:14,640
Answering them after a deny policy, fires in production costs

450
00:15:14,640 --> 00:15:15,400
you trust.

451
00:15:15,400 --> 00:15:17,600
The audit first principle is the rule here.

452
00:15:17,600 --> 00:15:19,680
Every policy that will eventually deny

453
00:15:19,680 --> 00:15:23,040
must start its life as an audit policy, not for a day,

454
00:15:23,040 --> 00:15:24,000
but for weeks.

455
00:15:24,000 --> 00:15:26,560
You need to see what it surfaces across your target scope.

456
00:15:26,560 --> 00:15:29,000
You'll find configuration patterns you didn't expect.

457
00:15:29,000 --> 00:15:31,360
You'll find legacy workloads that were grandfathered in,

458
00:15:31,360 --> 00:15:33,240
but never formally exempted.

459
00:15:33,240 --> 00:15:36,160
None of that complexity is visible until you run the policy

460
00:15:36,160 --> 00:15:38,080
in audit mode long enough to find it.

461
00:15:38,080 --> 00:15:40,440
The actual progression follows three phases.

462
00:15:40,440 --> 00:15:43,000
Audit, then modify, then deny.

463
00:15:43,000 --> 00:15:45,040
Audit gives you the visibility you need.

464
00:15:45,040 --> 00:15:48,040
Modify or deploy, if not exists, brings existing resources

465
00:15:48,040 --> 00:15:49,640
into compliance automatically.

466
00:15:49,640 --> 00:15:51,440
This shrinks the non-compliant population

467
00:15:51,440 --> 00:15:53,400
before you ever turn on the block switch.

468
00:15:53,400 --> 00:15:55,360
By the time you flip to deny, you've already

469
00:15:55,360 --> 00:15:56,800
fixed most of the violations.

470
00:15:56,800 --> 00:15:58,480
The blast radius is tiny because you've

471
00:15:58,480 --> 00:16:00,880
been systematically reducing it for weeks.

472
00:16:00,880 --> 00:16:04,360
Ring-based rollout makes this official across your hierarchy.

473
00:16:04,360 --> 00:16:07,040
Non-production management groups get the assignment first,

474
00:16:07,040 --> 00:16:10,280
then you move to pre-production, then to low-impact production.

475
00:16:10,280 --> 00:16:12,960
And finally, your most sensitive environments.

476
00:16:12,960 --> 00:16:15,720
At every transition, you run a compliance scan and a health

477
00:16:15,720 --> 00:16:18,600
check, you aren't guessing, you're measuring.

478
00:16:18,600 --> 00:16:20,800
The part most teams miss is that the technical work

479
00:16:20,800 --> 00:16:22,040
is only half the job.

480
00:16:22,040 --> 00:16:24,400
Communication matters just as much as the Jason.

481
00:16:24,400 --> 00:16:26,440
When denied policies go live, developers

482
00:16:26,440 --> 00:16:28,400
need to know what changed and how to fix it.

483
00:16:28,400 --> 00:16:30,440
A policy that blocks the deployment without context

484
00:16:30,440 --> 00:16:31,480
is just friction.

485
00:16:31,480 --> 00:16:33,760
But a policy that tells a developer exactly how

486
00:16:33,760 --> 00:16:35,480
to be compliant is a guardrail.

487
00:16:35,480 --> 00:16:37,720
That difference comes down to how you write your messages

488
00:16:37,720 --> 00:16:39,800
and how you prepare your teams.

489
00:16:39,800 --> 00:16:41,520
Policy rollout isn't a switch you flip.

490
00:16:41,520 --> 00:16:44,960
It's a deliberate, staged operation, policy as code,

491
00:16:44,960 --> 00:16:46,760
managing governance like software.

492
00:16:46,760 --> 00:16:49,360
Every organization is serious about as your governance

493
00:16:49,360 --> 00:16:51,200
eventually hits the same wall.

494
00:16:51,200 --> 00:16:53,680
You design the policies, you stage the rollout.

495
00:16:53,680 --> 00:16:54,920
Everything looks perfect.

496
00:16:54,920 --> 00:16:57,800
Then, six months later, someone logs into the portal.

497
00:16:57,800 --> 00:16:59,040
They tweak an assignment.

498
00:16:59,040 --> 00:17:00,760
They add an exemption without telling anyone.

499
00:17:00,760 --> 00:17:03,120
They change a parameter in a policy definition.

500
00:17:03,120 --> 00:17:03,960
And nobody knows.

501
00:17:03,960 --> 00:17:05,560
There is no record of who changed it.

502
00:17:05,560 --> 00:17:08,080
There is no way to test if the change was right.

503
00:17:08,080 --> 00:17:10,520
There is no way to roll it back when things break.

504
00:17:10,520 --> 00:17:12,920
Managing policy through the portal is a governance

505
00:17:12,920 --> 00:17:13,840
anti-pattern.

506
00:17:13,840 --> 00:17:16,280
It creates an environment that is impossible to audit,

507
00:17:16,280 --> 00:17:18,680
impossible to reproduce, and impossible to test.

508
00:17:18,680 --> 00:17:20,680
When your configuration lives in the portal,

509
00:17:20,680 --> 00:17:22,080
it exists in only one place.

510
00:17:22,080 --> 00:17:24,720
It exists in a state only the portal understands.

511
00:17:24,720 --> 00:17:26,200
Changed by whoever had the permissions

512
00:17:26,200 --> 00:17:27,360
and the urge to click around.

513
00:17:27,360 --> 00:17:28,440
That isn't infrastructure.

514
00:17:28,440 --> 00:17:30,280
That's improvisation.

515
00:17:30,280 --> 00:17:32,640
The shift that changes this is treating your governance

516
00:17:32,640 --> 00:17:34,320
exactly like application code.

517
00:17:34,320 --> 00:17:35,360
You use version control.

518
00:17:35,360 --> 00:17:36,600
You use peer reviews.

519
00:17:36,600 --> 00:17:38,600
You test every change before it goes live.

520
00:17:38,600 --> 00:17:40,360
You deploy through automated pipelines.

521
00:17:40,360 --> 00:17:41,520
This is policy as code.

522
00:17:41,520 --> 00:17:43,360
It turns governance from a manual task

523
00:17:43,360 --> 00:17:45,000
into an engineering discipline.

524
00:17:45,000 --> 00:17:45,960
The model starts and gets.

525
00:17:45,960 --> 00:17:48,240
Every policy definition lives in a repository.

526
00:17:48,240 --> 00:17:50,080
Every initiative and every assignment,

527
00:17:50,080 --> 00:17:51,920
including the parameters and the scope.

528
00:17:51,920 --> 00:17:53,800
Is a code artifact with a full history?

529
00:17:53,800 --> 00:17:56,480
Every exemption becomes a pull request with a reviewer,

530
00:17:56,480 --> 00:17:58,880
a justification and an expiration date

531
00:17:58,880 --> 00:17:59,960
written into the code.

532
00:17:59,960 --> 00:18:02,200
When an auditor asks what policies were active

533
00:18:02,200 --> 00:18:04,320
on a specific date, you don't check the portal.

534
00:18:04,320 --> 00:18:05,440
You check the git log.

535
00:18:05,440 --> 00:18:08,720
The pipeline for policy mirrors how you deploy software.

536
00:18:08,720 --> 00:18:11,560
A developer proposes a change, automated checks, run,

537
00:18:11,560 --> 00:18:14,720
syntax validation and unit tests, security and platform

538
00:18:14,720 --> 00:18:16,080
teams review the code.

539
00:18:16,080 --> 00:18:18,200
The pipeline deploys to a test group first,

540
00:18:18,200 --> 00:18:20,560
where integration tests prove the policy works.

541
00:18:20,560 --> 00:18:21,600
Once it passes.

542
00:18:21,600 --> 00:18:23,080
The change moves through your rings,

543
00:18:23,080 --> 00:18:25,040
from test to pre-production to production.

544
00:18:25,040 --> 00:18:26,560
No human touches the portal.

545
00:18:26,560 --> 00:18:28,080
The pipeline is the only way in.

546
00:18:28,080 --> 00:18:30,200
Bicep and Terraform are the two main ways to do this.

547
00:18:30,200 --> 00:18:31,560
Bicep is the native choice.

548
00:18:31,560 --> 00:18:33,520
It's built for Azure Resource Manager

549
00:18:33,520 --> 00:18:36,040
and works great if you stay within the Microsoft Stack.

550
00:18:36,040 --> 00:18:38,960
Terraform offers more flexibility for multi-cloud setups.

551
00:18:38,960 --> 00:18:40,960
And its state management makes it easier to see

552
00:18:40,960 --> 00:18:41,960
when things drift.

553
00:18:41,960 --> 00:18:44,120
But the tool matters less than the discipline.

554
00:18:44,120 --> 00:18:45,760
You aren't optimizing for syntax.

555
00:18:45,760 --> 00:18:48,960
You are optimizing for the audit trail, the repeatability.

556
00:18:48,960 --> 00:18:51,040
And the testing that only code provides,

557
00:18:51,040 --> 00:18:52,520
structure also matters.

558
00:18:52,520 --> 00:18:57,120
A single, massive repo for every policy becomes a mess as you grow.

559
00:18:57,120 --> 00:18:59,040
The model that scales is separate repositories

560
00:18:59,040 --> 00:19:00,040
for different domains.

561
00:19:00,040 --> 00:19:02,640
You have one for security baselines, one for cost,

562
00:19:02,640 --> 00:19:04,840
and one for regulatory compliance.

563
00:19:04,840 --> 00:19:06,600
Central templates live in a platform repo

564
00:19:06,600 --> 00:19:08,080
and get pulled in by the others.

565
00:19:08,080 --> 00:19:10,600
This keeps teams accountable for their own policies

566
00:19:10,600 --> 00:19:12,480
while keeping the process consistent.

567
00:19:12,480 --> 00:19:14,680
The real benefit here isn't just technical.

568
00:19:14,680 --> 00:19:16,360
When changes require pull requests,

569
00:19:16,360 --> 00:19:18,600
they require human review in the right context.

570
00:19:18,600 --> 00:19:20,960
A reviewer isn't guessing at a portal click.

571
00:19:20,960 --> 00:19:23,240
They are looking at a diff that shows exactly what changed

572
00:19:23,240 --> 00:19:24,000
and why.

573
00:19:24,000 --> 00:19:27,240
Every change is discussed, documented and traceable.

574
00:19:27,240 --> 00:19:30,480
The entire program becomes clear to everyone who needs to see it.

575
00:19:30,480 --> 00:19:33,320
Policy as code is how you make a stage deployment model

576
00:19:33,320 --> 00:19:34,240
last for years.

577
00:19:34,240 --> 00:19:36,640
Instead of just months, the RBIG drift problem.

578
00:19:36,640 --> 00:19:39,440
RBIG drift is dangerous because it looks like nothing is wrong.

579
00:19:39,440 --> 00:19:41,640
There is no alert, there is no failed deployment.

580
00:19:41,640 --> 00:19:43,200
There are no errors in your pipeline.

581
00:19:43,200 --> 00:19:45,720
The environment keeps running, workloads keep deploying,

582
00:19:45,720 --> 00:19:47,600
but underneath, the gap between your design

583
00:19:47,600 --> 00:19:49,000
and your reality gets wider.

584
00:19:49,000 --> 00:19:52,000
It happens quietly, consistently and invisibly.

585
00:19:52,000 --> 00:19:55,400
It stays hidden until an incident or an audit forces you to look at it.

586
00:19:55,400 --> 00:19:57,440
Here is how it starts, a project kicks off

587
00:19:57,440 --> 00:19:59,120
and needs a subscription fast.

588
00:19:59,120 --> 00:20:01,040
Someone gives three people owner rights

589
00:20:01,040 --> 00:20:04,000
because it's the easiest path and the work starts Monday.

590
00:20:04,000 --> 00:20:05,640
The project ends four months later.

591
00:20:05,640 --> 00:20:07,720
Two of those people move to different teams,

592
00:20:07,720 --> 00:20:08,800
but the permissions stay.

593
00:20:08,800 --> 00:20:11,160
Nobody removes them because nobody owns the cleanup.

594
00:20:11,160 --> 00:20:14,960
Now, multiply that by the emergency access granted during an outage.

595
00:20:14,960 --> 00:20:16,840
The contractor who got a direct assignment

596
00:20:16,840 --> 00:20:18,640
because there wasn't time for a group.

597
00:20:18,640 --> 00:20:21,360
The developer who needed contributor for one week.

598
00:20:21,360 --> 00:20:24,320
Six months ago, each choice was defensible at the time,

599
00:20:24,320 --> 00:20:26,560
but together, they create a permission model

600
00:20:26,560 --> 00:20:28,520
that looks nothing like the original plan.

601
00:20:28,520 --> 00:20:30,640
This is the slow identity drift problem.

602
00:20:30,640 --> 00:20:33,600
It is different from a misconfiguration you can catch with a policy.

603
00:20:33,600 --> 00:20:36,200
It doesn't announce itself, it doesn't trigger a compliance check.

604
00:20:36,200 --> 00:20:38,400
It just accumulates, assignment by assignment,

605
00:20:38,400 --> 00:20:40,920
until you find thousands of roles that nobody can explain.

606
00:20:40,920 --> 00:20:42,080
The cause is structural.

607
00:20:42,080 --> 00:20:44,240
RBIG was designed as a permission system.

608
00:20:44,240 --> 00:20:46,560
It was built to answer one question.

609
00:20:46,560 --> 00:20:49,360
Does this person have the right to do this action right now?

610
00:20:49,360 --> 00:20:50,960
It was not designed to govern itself.

611
00:20:50,960 --> 00:20:52,640
There is no expiration on a role.

612
00:20:52,640 --> 00:20:54,160
There is no built-in ownership.

613
00:20:54,160 --> 00:20:56,360
There is no automatic cleanup when a project ends

614
00:20:56,360 --> 00:20:58,280
without identity governance on top of our back,

615
00:20:58,280 --> 00:20:59,960
the model decays by default.

616
00:20:59,960 --> 00:21:01,440
And drift isn't just a headache.

617
00:21:01,440 --> 00:21:03,200
It is a direct security hole.

618
00:21:03,200 --> 00:21:06,200
Overprivileged accounts are the primary way cloud breaches happen.

619
00:21:06,200 --> 00:21:08,720
If an account with contributor rights is compromised,

620
00:21:08,720 --> 00:21:12,080
the attacker can steal data or change security settings instantly.

621
00:21:12,080 --> 00:21:14,680
The blast radius is limited only by what that role allows.

622
00:21:14,680 --> 00:21:16,200
The more drift you have, the bigger

623
00:21:16,200 --> 00:21:17,200
that radius becomes.

624
00:21:17,200 --> 00:21:18,720
There is a simple way to see this.

625
00:21:18,720 --> 00:21:20,280
Count your direct user assignments

626
00:21:20,280 --> 00:21:22,560
versus your group assignments in one subscription.

627
00:21:22,560 --> 00:21:24,800
Direct assignments are the fingerprints of drift.

628
00:21:24,800 --> 00:21:27,560
They show access granted outside of a controlled process,

629
00:21:27,560 --> 00:21:29,400
given to a person instead of a group,

630
00:21:29,400 --> 00:21:32,000
and likely never reviewed in a well-governed environment.

631
00:21:32,000 --> 00:21:33,600
Direct assignments are rare.

632
00:21:33,600 --> 00:21:35,800
In a drifting environment, they are everywhere.

633
00:21:35,800 --> 00:21:37,080
That count tells you the truth.

634
00:21:37,080 --> 00:21:39,600
It shows how much of your access is actually governed

635
00:21:39,600 --> 00:21:41,160
and how much is just there.

636
00:21:41,160 --> 00:21:43,120
Permissions held by people who don't need them

637
00:21:43,120 --> 00:21:44,440
in roles that are too broad

638
00:21:44,440 --> 00:21:46,440
at scopes that were never meant to be permanent.

639
00:21:46,440 --> 00:21:48,200
The solution isn't more audits.

640
00:21:48,200 --> 00:21:51,440
Auditing drift after it happens is expensive and reactive.

641
00:21:51,440 --> 00:21:52,680
The solution is architectural.

642
00:21:52,680 --> 00:21:54,920
You have to build RBAC in a way that makes drift

643
00:21:54,920 --> 00:21:57,440
structurally difficult to create in the first place.

644
00:21:57,440 --> 00:21:59,200
Designing RBAC that doesn't drift.

645
00:21:59,200 --> 00:22:01,080
Your RBAC model wasn't designed for scale.

646
00:22:01,080 --> 00:22:02,560
It was designed for convenience.

647
00:22:02,560 --> 00:22:05,800
Direct assignments, custom roles, ad hoc permissions.

648
00:22:05,800 --> 00:22:08,440
And the assumption that you can manage users one by one.

649
00:22:08,440 --> 00:22:10,000
That assumption is broken.

650
00:22:10,000 --> 00:22:12,720
Because at scale, work doesn't start with the user.

651
00:22:12,720 --> 00:22:13,680
It starts with the group.

652
00:22:13,680 --> 00:22:16,680
The fix starts with a rule that people violate constantly.

653
00:22:16,680 --> 00:22:18,680
You never assign RBAC directly to a person.

654
00:22:18,680 --> 00:22:20,960
You always assign it to enter ID security groups.

655
00:22:20,960 --> 00:22:23,280
This isn't just a preference or a tip for when you have time.

656
00:22:23,280 --> 00:22:25,640
It is a non-negotiable rule for your architecture.

657
00:22:25,640 --> 00:22:26,640
But here's the problem.

658
00:22:26,640 --> 00:22:29,600
When you link a role to a person, the permission moves with them.

659
00:22:29,600 --> 00:22:32,720
When they leave, the permission stays until someone remembers

660
00:22:32,720 --> 00:22:33,480
to delete it.

661
00:22:33,480 --> 00:22:34,800
That's where things change.

662
00:22:34,800 --> 00:22:37,640
When you assign a role to a group, the assignment stays stable.

663
00:22:37,640 --> 00:22:39,800
It doesn't matter who joins or leaves the company.

664
00:22:39,800 --> 00:22:42,120
The group membership changes, but the permission boundary stays

665
00:22:42,120 --> 00:22:43,640
exactly where you put it.

666
00:22:43,640 --> 00:22:46,400
So what's actually happening is you've separated the permission

667
00:22:46,400 --> 00:22:47,760
from the human life cycle.

668
00:22:47,760 --> 00:22:50,200
You manage the group through identity workflows and access

669
00:22:50,200 --> 00:22:50,960
reviews.

670
00:22:50,960 --> 00:22:52,360
You have a govern surface.

671
00:22:52,360 --> 00:22:53,920
But when you scatter direct assignments

672
00:22:53,920 --> 00:22:56,400
across hundreds of subscriptions, you have drift.

673
00:22:56,400 --> 00:22:59,320
Your governance is only as strong as your group management.

674
00:22:59,320 --> 00:23:01,360
If nobody reviews who is in the group,

675
00:23:01,360 --> 00:23:03,240
you've just moved the problem up one level.

676
00:23:03,240 --> 00:23:05,800
The group first model only works if the groups themselves

677
00:23:05,800 --> 00:23:06,280
are clean.

678
00:23:06,280 --> 00:23:07,360
You need access packages.

679
00:23:07,360 --> 00:23:08,800
You need approval workflows.

680
00:23:08,800 --> 00:23:10,160
You need membership to expire.

681
00:23:10,160 --> 00:23:12,120
The RBAC stays steady while the identity model

682
00:23:12,120 --> 00:23:14,480
underneath stays sharp and one level deeper.

683
00:23:14,480 --> 00:23:16,040
We have to talk about role design.

684
00:23:16,040 --> 00:23:17,360
Use built-in roles.

685
00:23:17,360 --> 00:23:18,960
Resist the urge to make custom ones.

686
00:23:18,960 --> 00:23:21,840
Every custom role you create is a debt you have to pay later.

687
00:23:21,840 --> 00:23:24,040
As your ads, new resource types all the time

688
00:23:24,040 --> 00:23:26,400
and your custom roles won't update themselves.

689
00:23:26,400 --> 00:23:28,720
When someone sees storage blob data contributor,

690
00:23:28,720 --> 00:23:29,920
they know what it does.

691
00:23:29,920 --> 00:23:32,840
When they see app team brought deploy custom V3,

692
00:23:32,840 --> 00:23:34,440
they have to go read the code.

693
00:23:34,440 --> 00:23:37,280
Built-in roles are documented and maintained by Microsoft.

694
00:23:37,280 --> 00:23:39,680
If you must use a custom role, treat it like code,

695
00:23:39,680 --> 00:23:42,120
version it, review it, document why it exists.

696
00:23:42,120 --> 00:23:43,320
Then there is the issue of scope.

697
00:23:43,320 --> 00:23:45,280
The old model says to assign permissions

698
00:23:45,280 --> 00:23:47,000
as close to the resource as possible.

699
00:23:47,000 --> 00:23:50,040
It feels safer, but in reality, it does the opposite.

700
00:23:50,040 --> 00:23:52,280
In a large environment, resource level assignments

701
00:23:52,280 --> 00:23:54,560
multiply until nobody can audit them.

702
00:23:54,560 --> 00:23:56,920
If you have 50 subscriptions and thousands of resources,

703
00:23:56,920 --> 00:23:58,840
you'll end up with a mess of fine grained permissions

704
00:23:58,840 --> 00:24:00,360
that are impossible to track.

705
00:24:00,360 --> 00:24:01,560
The new model is different.

706
00:24:01,560 --> 00:24:03,680
You assign at the highest level that makes sense

707
00:24:03,680 --> 00:24:05,760
like the subscription or resource group,

708
00:24:05,760 --> 00:24:07,960
then you use as your policy to restrict

709
00:24:07,960 --> 00:24:09,320
what people can actually do.

710
00:24:09,320 --> 00:24:11,000
You get simplicity at the permission layer

711
00:24:11,000 --> 00:24:12,760
and precision at the governance layer.

712
00:24:12,760 --> 00:24:13,920
Keep your numbers low.

713
00:24:13,920 --> 00:24:16,360
You should have no more than three owners per subscription.

714
00:24:16,360 --> 00:24:18,680
Keep high impact roles under 10 per scope.

715
00:24:18,680 --> 00:24:20,160
These aren't just random numbers.

716
00:24:20,160 --> 00:24:22,240
They represent the limit of what a human can actually

717
00:24:22,240 --> 00:24:24,040
understand during an incident.

718
00:24:24,040 --> 00:24:25,680
Beyond that, your access model is wider

719
00:24:25,680 --> 00:24:27,360
than your team's ability to manage it.

720
00:24:27,360 --> 00:24:29,800
Platform teams need different rights than app teams.

721
00:24:29,800 --> 00:24:32,720
Security needs to see everything but touch nothing.

722
00:24:32,720 --> 00:24:34,200
When you build these distinctions

723
00:24:34,200 --> 00:24:36,040
into the design from day one,

724
00:24:36,040 --> 00:24:38,480
everyone has exactly what they need.

725
00:24:38,480 --> 00:24:41,280
If you give everyone one broad role because it's easier,

726
00:24:41,280 --> 00:24:42,840
you're trading a little bit of time today

727
00:24:42,840 --> 00:24:44,840
for a massive security hole tomorrow.

728
00:24:44,840 --> 00:24:46,280
Blueprints and policy initiatives

729
00:24:46,280 --> 00:24:47,920
handle different parts of this.

730
00:24:47,920 --> 00:24:50,200
Blueprints set the baseline when you create an environment.

731
00:24:50,200 --> 00:24:52,800
Policy initiatives handle the compliance every day after that.

732
00:24:52,800 --> 00:24:54,160
One governs day zero,

733
00:24:54,160 --> 00:24:56,040
the other governs the rest of the timeline.

734
00:24:56,040 --> 00:24:57,520
Well designed, RBAC doesn't drift

735
00:24:57,520 --> 00:24:59,160
because the structure doesn't allow it,

736
00:24:59,160 --> 00:25:02,240
but even the best design needs a way to stay honest.

737
00:25:02,240 --> 00:25:03,040
PIM.

738
00:25:03,040 --> 00:25:05,280
Just in time access as a governance model.

739
00:25:05,280 --> 00:25:07,360
A clean RBAC model is a great start,

740
00:25:07,360 --> 00:25:08,960
but even a perfect setup has a flaw.

741
00:25:08,960 --> 00:25:10,760
It's the default behavior of Azure.

742
00:25:10,760 --> 00:25:12,480
When you make someone a permanent owner,

743
00:25:12,480 --> 00:25:14,800
that power is live 24 hours a day.

744
00:25:14,800 --> 00:25:15,840
It's there while they sleep.

745
00:25:15,840 --> 00:25:16,920
It's there on the weekend.

746
00:25:16,920 --> 00:25:19,040
If that account is hacked on a Sunday afternoon,

747
00:25:19,040 --> 00:25:20,800
the attacker doesn't have to work for it.

748
00:25:20,800 --> 00:25:22,040
The door is already open.

749
00:25:22,040 --> 00:25:23,720
This is the standing access problem.

750
00:25:23,720 --> 00:25:25,240
Most environments were built on the idea

751
00:25:25,240 --> 00:25:26,720
of permanent assignments.

752
00:25:26,720 --> 00:25:28,760
Zero trust rejects that the window of privilege

753
00:25:28,760 --> 00:25:31,080
should be measured in hours, not months.

754
00:25:31,080 --> 00:25:33,720
That is why we use privileged identity management or PIM.

755
00:25:33,720 --> 00:25:34,960
PIM changes the model.

756
00:25:34,960 --> 00:25:37,920
It creates a gap between being eligible and being active.

757
00:25:37,920 --> 00:25:39,760
An active assignment is always on.

758
00:25:39,760 --> 00:25:41,680
An eligible assignment is dormant.

759
00:25:41,680 --> 00:25:43,760
The user has permission to hold the role,

760
00:25:43,760 --> 00:25:46,840
but they don't actually have the power until they ask for it.

761
00:25:46,840 --> 00:25:48,960
When they activate it, the clock starts.

762
00:25:48,960 --> 00:25:52,320
When the time is up, the power vanishes automatically.

763
00:25:52,320 --> 00:25:55,760
Think about what this does to your attack surface.

764
00:25:55,760 --> 00:25:57,880
If a hacker steals credentials for a permanent owner,

765
00:25:57,880 --> 00:25:58,840
they win immediately.

766
00:25:58,840 --> 00:26:01,560
But if they steal credentials for an eligible PIM user,

767
00:26:01,560 --> 00:26:03,720
they get an account that has to ask for permission.

768
00:26:03,720 --> 00:26:05,160
They still have to pass MFA.

769
00:26:05,160 --> 00:26:06,200
They have to give a reason.

770
00:26:06,200 --> 00:26:08,800
They might have to wait for an admin to click approve.

771
00:26:08,800 --> 00:26:10,080
All of that creates noise.

772
00:26:10,080 --> 00:26:11,440
It gives you time to catch them.

773
00:26:11,440 --> 00:26:13,400
The blast radius is suddenly much smaller.

774
00:26:13,400 --> 00:26:15,400
You tune the controls based on the risk.

775
00:26:15,400 --> 00:26:17,560
MFA is the bare minimum for every activation.

776
00:26:17,560 --> 00:26:19,520
The justification field creates an audit trail

777
00:26:19,520 --> 00:26:21,320
that explains why the work is happening.

778
00:26:21,320 --> 00:26:24,000
For the big roles like global admin or subscription owner,

779
00:26:24,000 --> 00:26:26,280
you require a second person to approve the request.

780
00:26:26,280 --> 00:26:28,600
If an owner activation expires in two hours,

781
00:26:28,600 --> 00:26:30,480
that is a much lower risk than an assignment

782
00:26:30,480 --> 00:26:31,400
that lasts forever.

783
00:26:31,400 --> 00:26:32,840
PIM needs to cover two layers.

784
00:26:32,840 --> 00:26:35,840
You manage your Azure resource roles like contributor and owner.

785
00:26:35,840 --> 00:26:38,760
But you also manage your directory roles like global admin.

786
00:26:38,760 --> 00:26:41,040
Both layers need to follow the same JIT model.

787
00:26:41,040 --> 00:26:43,360
And there is a technical shift you need to see.

788
00:26:43,360 --> 00:26:47,840
PIM iteration two beta APIs are retiring on October 28, 2026.

789
00:26:47,840 --> 00:26:50,680
If you have scripts or pipelines using those old endpoints,

790
00:26:50,680 --> 00:26:51,720
they will break.

791
00:26:51,720 --> 00:26:54,920
You have to move to the PIM iteration three GA APIs.

792
00:26:54,920 --> 00:26:57,480
This isn't a suggestion and it won't happen on its own.

793
00:26:57,480 --> 00:27:00,080
If you haven't checked your automation lately, do it now.

794
00:27:00,080 --> 00:27:01,040
The deadline is real.

795
00:27:01,040 --> 00:27:02,800
Access reviews finish the cycle.

796
00:27:02,800 --> 00:27:04,680
PIM handles the moment someone needs power.

797
00:27:04,680 --> 00:27:07,240
Access reviews handle whether they should even be on the list.

798
00:27:07,240 --> 00:27:09,920
Every quarter you should look at who is eligible for these roles.

799
00:27:09,920 --> 00:27:13,360
If someone changed projects or left the team, you pull their eligibility.

800
00:27:13,360 --> 00:27:15,040
PIM controls the activation.

801
00:27:15,040 --> 00:27:16,880
Access reviews control the roster.

802
00:27:16,880 --> 00:27:20,280
Together they make sure that privileged access stays under control.

803
00:27:20,280 --> 00:27:22,160
Not just when you set it up, but every single day.

804
00:27:22,160 --> 00:27:27,920
If this changed how you think about governance, follow me, Mirko Peters on LinkedIn.

805
00:27:27,920 --> 00:27:29,560
The service principle crisis.

806
00:27:29,560 --> 00:27:31,920
PIM handles how humans get access.

807
00:27:31,920 --> 00:27:35,800
But there is a second identity problem in most Azure and M365 environments

808
00:27:35,800 --> 00:27:37,720
that works completely outside that model.

809
00:27:37,720 --> 00:27:41,760
And it is growing quietly in the background of almost every tenant I have ever looked at.

810
00:27:41,760 --> 00:27:44,000
Open your enter ID app registrations right now.

811
00:27:44,000 --> 00:27:46,080
Not the ones your platform team documented.

812
00:27:46,080 --> 00:27:46,720
All of them.

813
00:27:46,720 --> 00:27:52,320
Look for names like Project X integration test or Data Pipeline 10 2022 or Graph App do not delete.

814
00:27:52,320 --> 00:27:54,280
And count how many have client secrets.

815
00:27:54,280 --> 00:27:57,640
Then check how many of those secrets were last rotated more than 12 months ago.

816
00:27:57,640 --> 00:28:00,840
Then see how many of those app registrations actually have an owner listed.

817
00:28:00,840 --> 00:28:03,880
What you find in that exercise is the service principle crisis.

818
00:28:03,880 --> 00:28:05,440
It is not just one vulnerability.

819
00:28:05,440 --> 00:28:11,120
It is a population of them dozens or hundreds of application identities with permissions that made sense once.

820
00:28:11,120 --> 00:28:14,360
But they are just sitting in your tenant long after the original project died.

821
00:28:14,360 --> 00:28:16,800
The life cycle that creates this is predictable.

822
00:28:16,800 --> 00:28:19,600
A developer needs to connect to Microsoft Graph for a project.

823
00:28:19,600 --> 00:28:23,680
They create an app registration, generate a secret and grant the permissions the integration needs.

824
00:28:23,680 --> 00:28:27,480
Sometimes they scope it carefully, but other times they just grant tenant-wide mail.

825
00:28:27,480 --> 00:28:29,680
Read because that was the example in the documentation.

826
00:28:29,680 --> 00:28:34,360
The integration goes live six months later the project changes a year later the project ends.

827
00:28:34,360 --> 00:28:37,080
But the app registration stays the secret is still valid.

828
00:28:37,080 --> 00:28:40,760
The permissions are still active and because that developer moved to a different team.

829
00:28:40,760 --> 00:28:41,680
Nobody owns it.

830
00:28:41,680 --> 00:28:45,680
Nobody monitors the sign-ins and nobody asks if this identity should even exist.

831
00:28:45,680 --> 00:28:51,040
A service principle with tenant-wide permissions and a two-year-old secret will not show up as a critical alert on your dashboard.

832
00:28:51,040 --> 00:28:58,680
But that is exactly what it is an attacker who finds that secret in a leaked config file or a misconfigured repository inherits those permissions instantly.

833
00:28:58,680 --> 00:29:02,480
There is no MFA challenge. There is no approval workflow. There is no time limit.

834
00:29:02,480 --> 00:29:04,920
The credential works and the permissions are live.

835
00:29:04,920 --> 00:29:07,880
The ordered question that shows the scale of this is very specific.

836
00:29:07,880 --> 00:29:12,120
How many service principles in your tenant have no owner, no sign-in activity in the last 90 days,

837
00:29:12,120 --> 00:29:15,160
but still have permissions to read mailboxes or user data?

838
00:29:15,160 --> 00:29:19,320
In most environments, the answer is uncomfortable. It is not one or two. It is many.

839
00:29:19,320 --> 00:29:23,600
Each one is a loaded credential sitting in your environment owned by nobody and governed by nothing.

840
00:29:23,600 --> 00:29:25,000
The root cause is structural.

841
00:29:25,000 --> 00:29:29,640
Static credentials require humans to stay secure. Someone has to remember to rotate the secret.

842
00:29:29,640 --> 00:29:32,120
Someone has to delete the registration when the project ends.

843
00:29:32,120 --> 00:29:35,400
Someone has to notice when permissions are too broad and tighten them.

844
00:29:35,400 --> 00:29:38,680
Humans are not good at maintenance tasks that have no immediate penalty for failing.

845
00:29:38,680 --> 00:29:41,320
Rotation gets pushed back. Decommissioning gets forgotten.

846
00:29:41,320 --> 00:29:45,960
Scope reduction never happens because the integration works and nobody wants to risk breaking it.

847
00:29:45,960 --> 00:29:48,440
Static credentials escape your control by design.

848
00:29:48,440 --> 00:29:51,880
They get copied into configuration files. They end up in code repositories.

849
00:29:51,880 --> 00:29:56,200
They get pasted into pipeline variables by developers who do not know a better way.

850
00:29:56,200 --> 00:29:59,320
The credential leaves your controlled environment the moment it is created

851
00:29:59,320 --> 00:30:03,720
and from that point on you have no visibility into where it lives or who has it.

852
00:30:03,720 --> 00:30:06,920
You cannot audit your way out of this. The shift has to be architectural.

853
00:30:06,920 --> 00:30:10,280
You have to stop trusting the credential and start trusting the identity.

854
00:30:10,280 --> 00:30:13,480
When the question moves from is this secret valid or two,

855
00:30:13,480 --> 00:30:15,880
does this workload identity have permission?

856
00:30:15,880 --> 00:30:17,960
The entire attack surface changes.

857
00:30:17,960 --> 00:30:20,120
That shift is what managed identities are for.

858
00:30:20,120 --> 00:30:24,440
And why they are the only real answer to a crisis most companies have not named yet.

859
00:30:24,440 --> 00:30:27,960
Managed identities, how the trust model works.

860
00:30:27,960 --> 00:30:30,680
Managed identities are platform-issued workload identities.

861
00:30:30,680 --> 00:30:31,880
That phrase matters.

862
00:30:31,880 --> 00:30:34,680
Platform-issued means as your creates the identity,

863
00:30:34,680 --> 00:30:38,200
as your manages the credential and as your handles the rotation.

864
00:30:38,200 --> 00:30:39,960
The developer never generates a secret.

865
00:30:39,960 --> 00:30:42,440
They never store one. They never schedule a rotation task.

866
00:30:42,440 --> 00:30:45,400
They never accidentally paste a password into a config file.

867
00:30:45,400 --> 00:30:47,880
The entire mess of credential management simply disappears.

868
00:30:47,880 --> 00:30:49,160
Here is how it works.

869
00:30:49,160 --> 00:30:53,240
When you enable a managed identity on a resource like a function app or a virtual machine,

870
00:30:53,240 --> 00:30:55,960
enter ID registers that resource as an identity.

871
00:30:55,960 --> 00:30:58,760
It gets an object ID in your directory just like a user.

872
00:30:58,760 --> 00:31:00,200
You can assign our back roles to it.

873
00:31:00,200 --> 00:31:01,720
You can granted graph permissions.

874
00:31:01,720 --> 00:31:03,800
You can scope its access to exactly what it needs.

875
00:31:03,800 --> 00:31:07,800
The big difference is that the credential for that identity never leaves the Azure platform.

876
00:31:07,800 --> 00:31:11,480
When the workload needs to call another service like Key Vault or a SQL database,

877
00:31:11,480 --> 00:31:13,400
it calls a local metadata endpoint.

878
00:31:13,400 --> 00:31:15,640
The platform returns a short-lived token

879
00:31:15,640 --> 00:31:18,920
that is cryptographically signed and scoped to that specific task.

880
00:31:18,920 --> 00:31:20,680
The workload uses that token to log in,

881
00:31:20,680 --> 00:31:23,080
the token expires, the next call gets a fresh one.

882
00:31:23,080 --> 00:31:25,240
There is no password in the configuration

883
00:31:25,240 --> 00:31:27,000
and no certificate on the file system.

884
00:31:27,000 --> 00:31:30,440
There is no rotation process that fails because someone forgot to run a script.

885
00:31:30,440 --> 00:31:33,080
There are two types and the difference matters for governance.

886
00:31:33,080 --> 00:31:36,600
A system assigned managed identity is tied to one resource.

887
00:31:36,600 --> 00:31:39,640
If you delete the resource, the identity disappears automatically.

888
00:31:39,640 --> 00:31:41,240
That is a massive governance win.

889
00:31:41,240 --> 00:31:43,960
You do not need a separate process to clean up the identity

890
00:31:43,960 --> 00:31:46,440
because the infrastructure lifecycle handles it for you.

891
00:31:46,440 --> 00:31:49,000
A user assigned managed identity is different.

892
00:31:49,000 --> 00:31:52,280
You create it as a stand-alone resource and attach it to your compute.

893
00:31:52,280 --> 00:31:55,720
It can be shared across multiple resources, which helps reduce sprawl,

894
00:31:55,720 --> 00:31:57,720
but it does not die when the resource dies.

895
00:31:57,720 --> 00:32:02,040
It requires actual ownership and a plan to delete it when it is no longer needed.

896
00:32:02,040 --> 00:32:04,440
The trust model shift here is worth slowing down on.

897
00:32:04,440 --> 00:32:06,600
In the old service principle model, the question was,

898
00:32:06,600 --> 00:32:07,800
is this credential valid?

899
00:32:07,800 --> 00:32:09,400
If the secret matched, you were in.

900
00:32:09,400 --> 00:32:10,600
The credential was the proof.

901
00:32:10,600 --> 00:32:12,760
In the managed identity model, the question is,

902
00:32:12,760 --> 00:32:15,400
does this workload identity have permission at the scope?

903
00:32:15,400 --> 00:32:18,520
The platform verifies the identity when the token is issued.

904
00:32:18,520 --> 00:32:20,920
The RBIAC model decides what that identity can do.

905
00:32:20,920 --> 00:32:23,320
The token is the proof, and it is short-lived,

906
00:32:23,320 --> 00:32:25,800
unforgeable, and tied to a specific resource.

907
00:32:25,800 --> 00:32:27,400
This shift has real results.

908
00:32:27,400 --> 00:32:30,360
Organizations that move from secrets to managed identities

909
00:32:30,360 --> 00:32:34,280
see about a 95% reduction in the time spent managing credentials.

910
00:32:34,280 --> 00:32:35,560
That is not a small number.

911
00:32:35,560 --> 00:32:38,280
It represents the end of an entire category of work.

912
00:32:38,280 --> 00:32:39,960
You no longer have to generate secrets,

913
00:32:39,960 --> 00:32:42,920
distribute them securely, or monitor them for expiry.

914
00:32:42,920 --> 00:32:45,160
Managed identities make that work unnecessary.

915
00:32:45,160 --> 00:32:46,920
The developer experience is also much better.

916
00:32:46,920 --> 00:32:49,240
The Azure Identity SDK uses a class called

917
00:32:49,240 --> 00:32:52,120
default Azure Credential that handles the tokens for you.

918
00:32:52,120 --> 00:32:54,920
When a developer works locally, it uses their CLI login.

919
00:32:54,920 --> 00:32:57,240
In a pipeline, it uses the pipeline identity.

920
00:32:57,240 --> 00:32:59,480
In production, it uses the managed identity.

921
00:32:59,480 --> 00:33:01,400
The same code runs in all three places

922
00:33:01,400 --> 00:33:03,240
without changing any credential settings.

923
00:33:03,240 --> 00:33:05,560
The authentication just adapts to the environment.

924
00:33:05,560 --> 00:33:07,400
Developers stop thinking about credentials

925
00:33:07,400 --> 00:33:09,640
because the platform handles that layer.

926
00:33:09,640 --> 00:33:11,880
For zero trust, this is how you actually verify

927
00:33:11,880 --> 00:33:13,880
explicitly at the workload layer.

928
00:33:13,880 --> 00:33:16,520
Every single call between services is authenticated

929
00:33:16,520 --> 00:33:19,400
through EntraID with a verifiable short-lived token.

930
00:33:19,400 --> 00:33:22,600
There is no implicit trust based on where the server is sitting.

931
00:33:22,600 --> 00:33:25,560
There are no shared secrets that make it hard to tell who did what.

932
00:33:25,560 --> 00:33:28,040
The identity is clear, the permissions are explicit,

933
00:33:28,040 --> 00:33:30,520
and every event is logged in your sign in activity

934
00:33:30,520 --> 00:33:31,960
where you can audit it.

935
00:33:31,960 --> 00:33:34,520
Governing managed identities, where trust can break.

936
00:33:34,520 --> 00:33:36,920
Your security team probably thinks the problem is solved.

937
00:33:36,920 --> 00:33:39,800
They moved from service principles to managed identities.

938
00:33:39,800 --> 00:33:41,160
They stopped worrying about secrets,

939
00:33:41,160 --> 00:33:43,000
and they're right about half of the problem.

940
00:33:43,000 --> 00:33:46,040
But that half truth is exactly where your security program stalls.

941
00:33:46,040 --> 00:33:48,680
Managed identities fix the credential problem.

942
00:33:48,680 --> 00:33:50,600
They do not fix the authorization problem.

943
00:33:50,600 --> 00:33:52,280
The risk doesn't just vanish.

944
00:33:52,280 --> 00:33:54,520
It moves, and it moves somewhere less visible,

945
00:33:54,520 --> 00:33:56,120
which makes it much more dangerous.

946
00:33:56,120 --> 00:33:57,880
Here is how the attack actually works.

947
00:33:57,880 --> 00:34:00,440
If a workload is compromised, maybe through a code floor

948
00:34:00,440 --> 00:34:03,320
or a container escape, the attacker is already inside.

949
00:34:03,320 --> 00:34:04,760
They don't need to steal a password.

950
00:34:04,760 --> 00:34:06,520
They just call the Azure metadata service.

951
00:34:06,520 --> 00:34:08,840
The service sees the request coming from the right place

952
00:34:08,840 --> 00:34:10,440
and hands over a valid token.

953
00:34:10,440 --> 00:34:12,440
The attacker isn't stealing an identity.

954
00:34:12,440 --> 00:34:13,640
They are the identity.

955
00:34:13,640 --> 00:34:16,520
They inherit every single permission you gave that workload.

956
00:34:16,520 --> 00:34:19,480
If that identity has contributor rights on a subscription.

957
00:34:19,480 --> 00:34:21,560
The attacker now owns that subscription.

958
00:34:21,560 --> 00:34:23,560
The blast radius is defined by your choices.

959
00:34:23,560 --> 00:34:25,880
It's defined by how you scope that identity on day one.

960
00:34:25,880 --> 00:34:27,240
This is the IAM Trust Gap.

961
00:34:27,240 --> 00:34:28,840
The token system is working perfectly.

962
00:34:28,840 --> 00:34:31,400
The problem is the permissions on the other side of that token.

963
00:34:31,400 --> 00:34:33,720
Overprivileged managed identities are just the service

964
00:34:33,720 --> 00:34:35,640
principle crisis in a different shape.

965
00:34:35,640 --> 00:34:38,680
The only way to control this is through environment scoping.

966
00:34:38,680 --> 00:34:40,680
One identity, one lifecycle stage.

967
00:34:40,680 --> 00:34:43,960
You need a specific identity for dev, a different one for test,

968
00:34:43,960 --> 00:34:45,560
and a separate one for production.

969
00:34:45,560 --> 00:34:48,120
You can never share them if a dev environment gets hit.

970
00:34:48,120 --> 00:34:50,040
It should never be able to touch production.

971
00:34:50,040 --> 00:34:52,120
But if you use the same identity for both,

972
00:34:52,120 --> 00:34:53,160
that wall doesn't exist.

973
00:34:53,160 --> 00:34:55,400
Your architectural boundary is just a drawing.

974
00:34:55,400 --> 00:34:56,440
It isn't a control.

975
00:34:56,440 --> 00:34:59,480
You have to apply the same discipline here that you use for human users.

976
00:34:59,480 --> 00:35:01,480
Assign permissions at the resource level.

977
00:35:01,480 --> 00:35:02,680
Or the resource group level.

978
00:35:02,680 --> 00:35:05,320
Giving a managed identity access to a whole subscription

979
00:35:05,320 --> 00:35:06,920
should require a written reason.

980
00:35:06,920 --> 00:35:10,520
It isn't always wrong, but it expands the blast radius to everything.

981
00:35:10,520 --> 00:35:12,040
That needs to be a conscious choice.

982
00:35:12,040 --> 00:35:13,400
Not a lazy default.

983
00:35:13,400 --> 00:35:15,720
Every user assigned identity needs an owner,

984
00:35:15,720 --> 00:35:17,720
a purpose, and a plan for when it dies.

985
00:35:17,720 --> 00:35:20,280
Without those, you're just recreating the mess of

986
00:35:20,280 --> 00:35:21,880
often service principles.

987
00:35:21,880 --> 00:35:24,200
System assigned identities clean up after themselves.

988
00:35:24,200 --> 00:35:25,640
User assigned ones do not.

989
00:35:25,640 --> 00:35:29,240
An old identity sitting in production with active permissions is a ticking bomb.

990
00:35:29,240 --> 00:35:32,280
It's an often credential that doesn't show up on a secret audit.

991
00:35:32,280 --> 00:35:35,400
You have to use Azure Policy to keep this under control at scale.

992
00:35:35,400 --> 00:35:39,480
Set up policies that require managed identities for every resource that supports them.

993
00:35:39,480 --> 00:35:42,680
Block people from using client secrets when a managed identity is an option.

994
00:35:42,680 --> 00:35:45,000
Audit every identity that's missing an owner tag.

995
00:35:45,000 --> 00:35:47,800
Flag every subscription level permission for a manual review.

996
00:35:47,800 --> 00:35:49,880
These aren't tasks for a quarterly meeting.

997
00:35:49,880 --> 00:35:53,000
These are continuous checks running against every resource you own.

998
00:35:53,000 --> 00:35:54,520
You catch the mistake at deployment.

999
00:35:54,520 --> 00:35:57,000
Before it becomes govern instead, the trust model changed.

1000
00:35:57,000 --> 00:35:57,960
It didn't go away.

1001
00:35:57,960 --> 00:36:00,600
Govning it means treating workloads like people.

1002
00:36:00,600 --> 00:36:02,680
They must be scoped, documented,

1003
00:36:02,680 --> 00:36:06,040
and enforced by the same policy engine that runs the rest of your world.

1004
00:36:06,040 --> 00:36:09,000
Key Vault as a compliance control point.

1005
00:36:09,000 --> 00:36:11,320
Most people call Key Vault a secret store.

1006
00:36:11,320 --> 00:36:14,040
That's technically true, but it's also a massive understatement.

1007
00:36:14,040 --> 00:36:16,600
In a modern architecture, Key Vault is your trust anchor.

1008
00:36:16,600 --> 00:36:18,920
It's the one place where secrets and policy meet.

1009
00:36:18,920 --> 00:36:22,360
It's where your identity model finally connects to your data protection.

1010
00:36:22,360 --> 00:36:24,440
Key Vault does more than just hold onto passwords.

1011
00:36:24,440 --> 00:36:25,560
It gives you a single,

1012
00:36:25,560 --> 00:36:27,880
audited path to every secret in your estate.

1013
00:36:27,880 --> 00:36:32,120
It gives you HSM backed keys for workloads that need high-level hardware security.

1014
00:36:32,120 --> 00:36:35,720
That's the kind of thing auditors look for in PCI or healthcare environments.

1015
00:36:35,720 --> 00:36:37,320
It handles auto rotation,

1016
00:36:37,320 --> 00:36:41,000
which finally kills the manual processes that nobody ever actually did.

1017
00:36:41,000 --> 00:36:43,240
But the real value is the regulatory alignment.

1018
00:36:43,240 --> 00:36:47,800
Azure Policy has definitions that map directly to ISO 27001 and NIST standards.

1019
00:36:47,800 --> 00:36:49,400
You don't have to build the evidence manually.

1020
00:36:49,400 --> 00:36:50,680
You assign the policy.

1021
00:36:50,680 --> 00:36:52,920
And the compliance data starts generating itself.

1022
00:36:52,920 --> 00:36:55,480
But there is a shift happening right now that you cannot ignore.

1023
00:36:55,480 --> 00:36:57,720
The old access policy model is a liability.

1024
00:36:57,720 --> 00:37:01,960
It uses a flat list of permissions that doesn't talk to the rest of Azure R-BAC.

1025
00:37:01,960 --> 00:37:05,320
It creates islands of access that your central team can't see or audit.

1026
00:37:05,320 --> 00:37:07,480
The standard is now R-BAC based authorization.

1027
00:37:07,480 --> 00:37:10,840
You should be using policy to deny any vault that still uses the old model.

1028
00:37:10,840 --> 00:37:14,040
For existing vaults, the path to migrate is already there.

1029
00:37:14,040 --> 00:37:15,640
This isn't a suggestion for next year.

1030
00:37:15,640 --> 00:37:17,000
It's the baseline for right now.

1031
00:37:17,000 --> 00:37:20,120
If you're running a production vault, secure isn't a vague goal.

1032
00:37:20,120 --> 00:37:21,400
It's a list of settings.

1033
00:37:21,400 --> 00:37:23,640
Soft delete must be on with a 90-day window.

1034
00:37:23,640 --> 00:37:25,320
Perge protection must be enabled.

1035
00:37:25,320 --> 00:37:28,440
This stops even an admin from wiping data during that 90-day period.

1036
00:37:28,440 --> 00:37:30,840
Without it, soft delete is just a recovery tool.

1037
00:37:30,840 --> 00:37:31,960
Not a security control.

1038
00:37:31,960 --> 00:37:33,480
Public access has to be off.

1039
00:37:33,480 --> 00:37:35,320
You use private endpoints only.

1040
00:37:35,320 --> 00:37:38,440
And your logs need to go to a central log analytics workspace.

1041
00:37:38,440 --> 00:37:41,000
Don't send them to a storage account where they'll be forgotten.

1042
00:37:41,000 --> 00:37:42,840
Send them where your alerts actually fire.

1043
00:37:42,840 --> 00:37:45,560
Every one of these settings can be enforced by Azure Policy.

1044
00:37:45,560 --> 00:37:47,160
You deny vaults without soft delete.

1045
00:37:47,160 --> 00:37:49,080
You deploy diagnostic settings automatically.

1046
00:37:49,080 --> 00:37:50,440
You audit for public access.

1047
00:37:50,440 --> 00:37:51,800
You require private endpoints.

1048
00:37:51,800 --> 00:37:55,080
This is the difference between a PDF of security standards and a guardrail.

1049
00:37:55,080 --> 00:37:57,640
The policy turns a written rule into a technical reality.

1050
00:37:57,640 --> 00:38:00,680
And just like identities, environment separation is mandatory.

1051
00:38:00,680 --> 00:38:03,400
A dev vault and a production vault are not the same thing.

1052
00:38:03,400 --> 00:38:04,520
They hold different secrets.

1053
00:38:04,520 --> 00:38:05,720
They have different risks.

1054
00:38:05,720 --> 00:38:09,160
If you share a vault across stages, you've collapsed your isolation boundary.

1055
00:38:09,160 --> 00:38:11,320
It's the same mistake as sharing an identity.

1056
00:38:11,320 --> 00:38:13,960
One vault per environment governed by the same baseline

1057
00:38:13,960 --> 00:38:15,640
with separate permissions for each.

1058
00:38:15,640 --> 00:38:17,240
When your vaults are consistent,

1059
00:38:17,240 --> 00:38:19,320
the whole architecture becomes trustworthy.

1060
00:38:19,320 --> 00:38:21,320
Identities get secrets without passwords.

1061
00:38:21,320 --> 00:38:23,640
Pipelines get certificates without touching them.

1062
00:38:23,640 --> 00:38:25,800
Auditors get clear logs without any gaps.

1063
00:38:25,800 --> 00:38:27,480
Key vault stops being a box for secrets.

1064
00:38:27,480 --> 00:38:30,280
It becomes the point where you actually govern access.

1065
00:38:30,600 --> 00:38:33,720
Key vault in CICD, secrets without exposure.

1066
00:38:33,720 --> 00:38:34,840
You've set up your vault.

1067
00:38:34,840 --> 00:38:35,640
It's secure.

1068
00:38:35,640 --> 00:38:37,080
It has policies.

1069
00:38:37,080 --> 00:38:40,280
But a vault that nobody uses correctly is just a well-governed place

1070
00:38:40,280 --> 00:38:43,000
where secrets sit before they get mishandled somewhere else.

1071
00:38:43,000 --> 00:38:46,600
The real test for your architecture happens inside your deployment pipelines.

1072
00:38:46,600 --> 00:38:48,920
That's where secrets have always been most exposed.

1073
00:38:48,920 --> 00:38:51,080
And that's where the combination of managed identities

1074
00:38:51,080 --> 00:38:54,360
and key vault either closes the loop or leaves a massive gap.

1075
00:38:54,360 --> 00:38:55,720
The rule here is simple.

1076
00:38:55,720 --> 00:38:59,960
Secrets must never live in code, configuration files, or pipeline variables.

1077
00:38:59,960 --> 00:39:00,920
This isn't a suggestion.

1078
00:39:00,920 --> 00:39:03,800
It's an architectural constraint with zero exceptions.

1079
00:39:03,800 --> 00:39:07,000
Every time a secret appears as a pipeline variable, it leaves a trail.

1080
00:39:07,000 --> 00:39:07,720
It gets logged.

1081
00:39:07,720 --> 00:39:10,280
It shows up in build outputs that get archived.

1082
00:39:10,280 --> 00:39:13,880
It exists in configuration stores that anyone with pipeline access can read.

1083
00:39:13,880 --> 00:39:16,280
The attack surface of a secret in a pipeline variable

1084
00:39:16,280 --> 00:39:17,880
isn't just the pipeline itself.

1085
00:39:17,880 --> 00:39:20,920
It's every system that pipeline touches, every log that gets shipped

1086
00:39:20,920 --> 00:39:23,640
and every person who has ever looked at the configuration.

1087
00:39:23,640 --> 00:39:25,560
The surface is much larger than it looks.

1088
00:39:25,560 --> 00:39:28,840
The managed identity model fixes this by removing the human from the path.

1089
00:39:28,840 --> 00:39:30,280
Here is how the flow actually works.

1090
00:39:30,280 --> 00:39:32,920
Your pipeline agent runs under a managed identity.

1091
00:39:32,920 --> 00:39:35,320
This applies whether you use an Azure DevOps agent,

1092
00:39:35,320 --> 00:39:38,360
a GitHub actions runner, or a task in a fabric pipeline.

1093
00:39:38,360 --> 00:39:39,880
When the deployment needs a secret,

1094
00:39:39,880 --> 00:39:42,680
the agent calls key vault using its identity token.

1095
00:39:42,680 --> 00:39:45,560
It grabs the secret at runtime and uses it for the task.

1096
00:39:45,560 --> 00:39:47,560
The value never appears in an artifact.

1097
00:39:47,560 --> 00:39:48,760
It never shows up in a log.

1098
00:39:48,760 --> 00:39:50,360
It never sits in a config file.

1099
00:39:50,360 --> 00:39:52,920
The secret moves directly from the vault into memory

1100
00:39:52,920 --> 00:39:54,440
for the duration of the operation.

1101
00:39:54,440 --> 00:39:55,640
It doesn't rest anywhere.

1102
00:39:55,640 --> 00:39:56,920
A human can read it.

1103
00:39:56,920 --> 00:39:59,480
And it doesn't stay behind once the task is finished.

1104
00:39:59,480 --> 00:40:01,880
We see this clearly in the Microsoft fabric pattern.

1105
00:40:01,880 --> 00:40:03,720
Many organizations run fabric pipelines

1106
00:40:03,720 --> 00:40:06,520
with secrets buried in notebook code or connection strings.

1107
00:40:06,520 --> 00:40:08,440
They are carrying a risk that managed identities

1108
00:40:08,440 --> 00:40:10,280
were specifically designed to fix.

1109
00:40:10,280 --> 00:40:11,720
The fix is a direct sequence.

1110
00:40:11,720 --> 00:40:13,400
First, you inventory every pipeline

1111
00:40:13,400 --> 00:40:15,000
and notebook that holds a credential.

1112
00:40:15,000 --> 00:40:18,040
Then you enable managed identity for those fabric resources.

1113
00:40:18,040 --> 00:40:20,680
You move every secret into key vault and grant the resource

1114
00:40:20,680 --> 00:40:22,280
the key vault secrets user role.

1115
00:40:22,280 --> 00:40:24,280
Make sure you scope this to specific secrets

1116
00:40:24,280 --> 00:40:25,480
rather than the whole vault.

1117
00:40:25,480 --> 00:40:27,960
Once that's done, you delete the embedded credentials.

1118
00:40:27,960 --> 00:40:29,800
The pipeline still works exactly the same way

1119
00:40:29,800 --> 00:40:32,280
but the credential handling has changed completely.

1120
00:40:32,280 --> 00:40:35,000
This same logic applies to graph API integrations.

1121
00:40:35,000 --> 00:40:37,800
If you use client certificates, store them in key vault.

1122
00:40:37,800 --> 00:40:39,560
Do not put them in your app settings file

1123
00:40:39,560 --> 00:40:40,920
or your pipeline variables.

1124
00:40:40,920 --> 00:40:43,080
Configure your pipeline to fetch that certificate

1125
00:40:43,080 --> 00:40:45,000
at runtime using the agent's identity.

1126
00:40:45,000 --> 00:40:47,000
Now, your application authenticates to graph

1127
00:40:47,000 --> 00:40:49,480
using a certificate from a governed, audited vault.

1128
00:40:49,480 --> 00:40:51,080
Every access event is logged

1129
00:40:51,080 --> 00:40:52,680
that is a much stronger position

1130
00:40:52,680 --> 00:40:55,000
than having a certificate sitting in a config file

1131
00:40:55,000 --> 00:40:57,160
that gets bundled into a deployment package.

1132
00:40:57,160 --> 00:40:58,840
Static analysis is the guardrail

1133
00:40:58,840 --> 00:41:01,160
that catches mistakes before they reach the vault.

1134
00:41:01,160 --> 00:41:03,800
Automated credential scanning tools look at code diffs

1135
00:41:03,800 --> 00:41:06,520
for patterns that look like secrets or API keys.

1136
00:41:06,520 --> 00:41:08,600
This happens as a gate before any merge.

1137
00:41:08,600 --> 00:41:09,800
It isn't a manual review.

1138
00:41:09,800 --> 00:41:12,040
It's an automated check that fails the pipeline

1139
00:41:12,040 --> 00:41:13,720
the moment a secret is detected.

1140
00:41:13,720 --> 00:41:15,400
The developer gets feedback immediately.

1141
00:41:15,400 --> 00:41:17,800
They see the error before the code enters the repo

1142
00:41:17,800 --> 00:41:19,800
and before it becomes part of an archive.

1143
00:41:19,800 --> 00:41:21,800
You can extend this to the infrastructure layer

1144
00:41:21,800 --> 00:41:23,160
with policy validation.

1145
00:41:23,160 --> 00:41:26,120
By using policy state evaluations inside the pipeline

1146
00:41:26,120 --> 00:41:28,760
you ensure that infrastructure code follows your baseline.

1147
00:41:28,760 --> 00:41:30,440
If a bicep template tries to create a vault

1148
00:41:30,440 --> 00:41:31,560
without purge protection,

1149
00:41:31,560 --> 00:41:34,520
the pipeline fails before it ever starts the deployment.

1150
00:41:34,520 --> 00:41:36,200
The rules you defined in a zure policy

1151
00:41:36,200 --> 00:41:38,200
are mirrored in the pre-deployment layer.

1152
00:41:38,200 --> 00:41:39,880
Violations show up during development

1153
00:41:39,880 --> 00:41:42,280
rather than during a compliance scan weeks later.

1154
00:41:42,280 --> 00:41:45,480
The endstatus of pipeline where no engineer ever touches a credential.

1155
00:41:45,480 --> 00:41:47,320
Every access is logged in diagnostics.

1156
00:41:47,320 --> 00:41:49,960
Rotating a secret means changing it in one vault

1157
00:41:49,960 --> 00:41:51,480
not hunting through 100 configs

1158
00:41:51,480 --> 00:41:54,600
and repositories to find every place it was copied.

1159
00:41:54,600 --> 00:41:57,000
Can security teams trust developer self-service?

1160
00:41:57,000 --> 00:41:57,960
The question is simple.

1161
00:41:57,960 --> 00:41:59,480
Can you give developers autonomy

1162
00:41:59,480 --> 00:42:02,600
without creating the gaps that keep security teams awake at night?

1163
00:42:02,600 --> 00:42:05,080
In most companies this never gets asked directly.

1164
00:42:05,080 --> 00:42:07,560
Instead it gets answered by the length of the ticket queue.

1165
00:42:07,560 --> 00:42:09,560
It gets answered by the shadow IT problem.

1166
00:42:09,560 --> 00:42:12,120
It gets answered by the number of exceptions granted

1167
00:42:12,120 --> 00:42:14,360
because the official path is too slow.

1168
00:42:14,360 --> 00:42:16,040
The traditional answer is no.

1169
00:42:16,040 --> 00:42:18,280
Security teams stay in control by being a bottleneck.

1170
00:42:18,280 --> 00:42:19,720
Every request goes through them.

1171
00:42:19,720 --> 00:42:21,720
Every service connection gets a review.

1172
00:42:21,720 --> 00:42:24,040
Every production deployment needs a sign off.

1173
00:42:24,040 --> 00:42:25,240
The logic sounds right.

1174
00:42:25,240 --> 00:42:26,680
Humans prevent mistakes.

1175
00:42:26,680 --> 00:42:28,040
But look at what actually happens.

1176
00:42:28,040 --> 00:42:29,720
Developers find ways around the system.

1177
00:42:29,720 --> 00:42:31,240
They create personal subscriptions.

1178
00:42:31,240 --> 00:42:32,920
They reuse old service principles

1179
00:42:32,920 --> 00:42:35,240
because waiting three weeks for a new one isn't an option.

1180
00:42:35,240 --> 00:42:37,320
They store credentials in unmoneted places

1181
00:42:37,320 --> 00:42:39,160
because the approved vault process

1182
00:42:39,160 --> 00:42:41,160
takes longer than the entire sprint.

1183
00:42:41,160 --> 00:42:42,760
The security team didn't lose control

1184
00:42:42,760 --> 00:42:44,600
because developers were being difficult.

1185
00:42:44,600 --> 00:42:47,320
They lost it because the friction made the insecure path faster

1186
00:42:47,320 --> 00:42:48,520
than the secure one.

1187
00:42:48,520 --> 00:42:51,000
The answer to the trust question isn't a yes or a no.

1188
00:42:51,000 --> 00:42:52,280
It's a design choice.

1189
00:42:52,280 --> 00:42:54,280
Trust isn't something you grant to a person.

1190
00:42:54,280 --> 00:42:56,120
It's something you build into the platform.

1191
00:42:56,120 --> 00:42:58,040
When the system enforces the standards

1192
00:42:58,040 --> 00:42:59,640
when a bad resource can't be deployed

1193
00:42:59,640 --> 00:43:01,080
because as your policy blocks it,

1194
00:43:01,080 --> 00:43:03,400
the approval loop becomes unnecessary.

1195
00:43:03,400 --> 00:43:06,360
The security team doesn't need to look at every deployment

1196
00:43:06,360 --> 00:43:08,040
because the infrastructure already knows

1197
00:43:08,040 --> 00:43:09,240
what they would have approved.

1198
00:43:09,240 --> 00:43:11,400
This is the difference between guardrails and gates.

1199
00:43:11,400 --> 00:43:13,480
A gate is a human decision that stops progress

1200
00:43:13,480 --> 00:43:14,360
until someone says,

1201
00:43:14,360 --> 00:43:17,480
"Okay, gates create queues, queues create pressure.

1202
00:43:17,480 --> 00:43:19,000
pressure leads to exceptions

1203
00:43:19,000 --> 00:43:21,480
and eventually those exceptions become the new normal."

1204
00:43:21,480 --> 00:43:23,320
A guardrail is a system constraint.

1205
00:43:23,320 --> 00:43:24,680
It prevents unsafe actions

1206
00:43:24,680 --> 00:43:27,000
but lets everything else move forward without stopping.

1207
00:43:27,000 --> 00:43:30,200
If a developer tries to deploy a storage account with public access

1208
00:43:30,200 --> 00:43:32,680
the policy engine gives them an error immediately.

1209
00:43:32,680 --> 00:43:34,360
Everything else deploys fine.

1210
00:43:34,360 --> 00:43:35,960
There is no queue, there is no waiting.

1211
00:43:35,960 --> 00:43:39,560
There is no exception because the violation was caught before it ever existed

1212
00:43:39,560 --> 00:43:40,520
in the environment.

1213
00:43:40,520 --> 00:43:43,320
Erster Digital is a great example of this model in action.

1214
00:43:43,320 --> 00:43:46,840
They are a financial organization with over 40 development teams.

1215
00:43:46,840 --> 00:43:49,240
They manage over a thousand terraform workspaces

1216
00:43:49,240 --> 00:43:51,720
or running within guardrails enforced by the platform.

1217
00:43:51,720 --> 00:43:53,560
Developers provision their own environments.

1218
00:43:53,560 --> 00:43:54,680
They don't wait for tickets.

1219
00:43:54,680 --> 00:43:56,360
The platform teams define the standards

1220
00:43:56,360 --> 00:43:58,520
and build them into the modules and templates.

1221
00:43:58,520 --> 00:44:01,640
The speed comes from removing the human from the approval path.

1222
00:44:01,640 --> 00:44:04,920
The security comes from the fact that the platform won't let them break the rules

1223
00:44:04,920 --> 00:44:05,960
even if they try.

1224
00:44:05,960 --> 00:44:08,680
When you see a 70% reduction in onboarding time,

1225
00:44:08,680 --> 00:44:10,120
it isn't just about the tools.

1226
00:44:10,120 --> 00:44:11,640
It's about the organizational model.

1227
00:44:11,640 --> 00:44:13,960
The bottleneck in a ticket system isn't the work itself.

1228
00:44:13,960 --> 00:44:15,800
It's the handoff, it's the queue.

1229
00:44:15,800 --> 00:44:18,440
It's the context switching for the person reading the request.

1230
00:44:18,440 --> 00:44:20,680
When a developer can spin up a governed environment

1231
00:44:20,680 --> 00:44:23,240
that already has the right networking and identity setup,

1232
00:44:23,240 --> 00:44:25,480
the time collapses, the handoff simply disappears.

1233
00:44:25,480 --> 00:44:29,800
For security leaders, this is a massive shift in your role.

1234
00:44:29,800 --> 00:44:31,800
The question is no longer, did I approve this?

1235
00:44:31,800 --> 00:44:33,800
The question is, did I design a system

1236
00:44:33,800 --> 00:44:35,800
where unsafe deployments are impossible?

1237
00:44:35,800 --> 00:44:38,520
The first question only scales as far as one person can read.

1238
00:44:38,520 --> 00:44:41,560
The second question scales to every team the platform touches.

1239
00:44:41,560 --> 00:44:43,880
One architect who builds a strong policy baseline

1240
00:44:43,880 --> 00:44:47,160
has more impact than a whole team of people processing tickets.

1241
00:44:47,160 --> 00:44:50,200
The leverage comes from the infrastructure, not from the approval chain.

1242
00:44:50,200 --> 00:44:52,040
Security teams that haven't made this move

1243
00:44:52,040 --> 00:44:53,720
are working harder than everyone else

1244
00:44:53,720 --> 00:44:55,000
and they're getting worse results.

1245
00:44:55,000 --> 00:44:56,600
The Golden Path.

1246
00:44:56,600 --> 00:44:59,000
Building self-service that enforces standards.

1247
00:44:59,000 --> 00:45:01,800
The guardrail's not Gates model tells you what to build toward.

1248
00:45:01,800 --> 00:45:05,160
The Golden Path tells you how to build it, so developers actually use it.

1249
00:45:05,160 --> 00:45:07,720
A Golden Path is a pre-approved, pre-configured workflow

1250
00:45:07,720 --> 00:45:11,000
where the easiest way to deploy something is also the compliant way to deploy it.

1251
00:45:11,000 --> 00:45:14,920
It isn't a restrictive tunnel that forces developers through a narrow experience.

1252
00:45:14,920 --> 00:45:18,440
Think of it as a well-lit road with good signage and no potholes.

1253
00:45:18,440 --> 00:45:20,120
One that happens to have barriers on the sides

1254
00:45:20,120 --> 00:45:21,960
preventing anyone from driving off a cliff.

1255
00:45:21,960 --> 00:45:24,440
The developers who use it aren't thinking about compliance.

1256
00:45:24,440 --> 00:45:25,720
They're thinking about shipping.

1257
00:45:25,720 --> 00:45:29,640
The compliance is happening underneath them, invisibly, by design.

1258
00:45:29,640 --> 00:45:32,840
What a Golden Path actually contains isn't a single artifact.

1259
00:45:32,840 --> 00:45:34,120
It's a layered package.

1260
00:45:34,120 --> 00:45:37,160
You have IRC modules with security baselines already baked in.

1261
00:45:37,160 --> 00:45:39,720
A network module might deploy with private endpoints

1262
00:45:39,720 --> 00:45:41,160
configured by default,

1263
00:45:41,160 --> 00:45:43,000
while a storage module enables encryption

1264
00:45:43,000 --> 00:45:46,200
and disables public access before the developer writes a single parameter.

1265
00:45:46,200 --> 00:45:50,360
A key vault module creates a vault with R-back authorization,

1266
00:45:50,360 --> 00:45:53,240
purge protection, and diagnostic logging already wired.

1267
00:45:53,240 --> 00:45:57,400
These aren't options the developer might enable if they remember to read the documentation.

1268
00:45:57,400 --> 00:46:00,200
They are the defaults they'd have to deliberately override.

1269
00:46:00,200 --> 00:46:02,440
Every module in the catalog encodes a standard.

1270
00:46:02,440 --> 00:46:04,600
Using the module is how you meet the standard.

1271
00:46:04,600 --> 00:46:06,440
Pipeline templates work the same way.

1272
00:46:06,440 --> 00:46:08,920
The platform team publishes a deployment pipeline template

1273
00:46:08,920 --> 00:46:11,240
that includes credential scanning as a pre-merge gate,

1274
00:46:11,240 --> 00:46:13,720
policy validation before infrastructure deployment,

1275
00:46:13,720 --> 00:46:17,320
and key vault secret retrieval via managed identity already configured.

1276
00:46:17,320 --> 00:46:20,200
A developer who consumes that template gets all of those controls

1277
00:46:20,200 --> 00:46:21,560
without implementing any of them.

1278
00:46:21,560 --> 00:46:24,600
The compliance work happened when the platform team built the template.

1279
00:46:24,600 --> 00:46:26,360
The developer benefits from it automatically.

1280
00:46:26,360 --> 00:46:28,520
The delivery mechanism for these modules and templates

1281
00:46:28,520 --> 00:46:30,360
is the internal developer portal.

1282
00:46:30,360 --> 00:46:32,360
Backstage or an equivalent catalog surface

1283
00:46:32,360 --> 00:46:36,760
that exposes Golden Paths as self-service actions developers can trigger directly.

1284
00:46:36,760 --> 00:46:38,360
You can create a new microservice.

1285
00:46:38,360 --> 00:46:41,880
Provision a dev environment, or register a new API.

1286
00:46:41,880 --> 00:46:43,880
Each action maps to a pre-approved workflow

1287
00:46:43,880 --> 00:46:47,320
that calls the right IAC module runs through the right pipeline template

1288
00:46:47,320 --> 00:46:49,400
and produces an environment that's compliant

1289
00:46:49,400 --> 00:46:51,480
from the first resource created.

1290
00:46:51,480 --> 00:46:54,600
The portal makes the secure path discoverable and convenient.

1291
00:46:54,600 --> 00:46:56,440
Convenience drives adoption more reliably

1292
00:46:56,440 --> 00:46:58,520
than any policy mandate ever will.

1293
00:46:58,520 --> 00:47:01,400
Roll-based boundaries define what self-service means at each level.

1294
00:47:01,400 --> 00:47:03,960
Developers can provision anything within their landing zone.

1295
00:47:03,960 --> 00:47:07,400
They can create resources, configure services, and deploy applications.

1296
00:47:07,400 --> 00:47:09,480
What they can't do is escape the guardrails.

1297
00:47:09,480 --> 00:47:12,200
And the guardrails aren't enforced by a person who might be in a meeting.

1298
00:47:12,200 --> 00:47:15,480
They're enforced by Azure Policy at the management group level,

1299
00:47:15,480 --> 00:47:18,520
which evaluates every deployment against the defined standards

1300
00:47:18,520 --> 00:47:20,200
before resources are created.

1301
00:47:20,200 --> 00:47:22,520
A developer who tries to deploy a resource configuration

1302
00:47:22,520 --> 00:47:24,200
the Golden Path doesn't support

1303
00:47:24,200 --> 00:47:27,000
against a specific actionable error at deployment time,

1304
00:47:27,000 --> 00:47:29,080
not a ticket rejection three days later.

1305
00:47:29,080 --> 00:47:33,240
The policy enforcement points in a well-designed Golden Path run at two distinct layers.

1306
00:47:33,240 --> 00:47:35,720
IAC linter's catch violations during development.

1307
00:47:35,720 --> 00:47:39,240
Before the pipeline even runs before any Azure API gets called,

1308
00:47:39,240 --> 00:47:41,960
a developer who accidentally removes the purge protection parameter

1309
00:47:41,960 --> 00:47:44,440
from a vault module sees a linting error in their editor

1310
00:47:44,440 --> 00:47:45,800
or in the pull request check.

1311
00:47:45,800 --> 00:47:48,440
The outer layer is Azure Policy at the management group level,

1312
00:47:48,440 --> 00:47:50,840
which catches anything that made it past the linter

1313
00:47:50,840 --> 00:47:53,960
and evaluates it against the same standards the linter was checking.

1314
00:47:53,960 --> 00:47:55,960
These are two independent enforcement points,

1315
00:47:55,960 --> 00:47:58,760
each serving a different part of the development cycle.

1316
00:47:58,760 --> 00:48:01,560
Measuring whether the Golden Path is working requires metrics

1317
00:48:01,560 --> 00:48:04,280
that reflect actual behavior, not activity.

1318
00:48:04,280 --> 00:48:07,640
You want to see the percentage of deployments executed through platform pipelines

1319
00:48:07,640 --> 00:48:09,400
versus ad hoc manual deployments.

1320
00:48:09,400 --> 00:48:11,720
You should track the time from repository creation

1321
00:48:11,720 --> 00:48:13,400
to the first working environment.

1322
00:48:13,400 --> 00:48:16,200
You also need to look at the change failure rate for deployments

1323
00:48:16,200 --> 00:48:19,160
through the standard path compared to deployments that bypassed it.

1324
00:48:19,160 --> 00:48:22,120
These numbers tell you whether developers are choosing the Golden Path

1325
00:48:22,120 --> 00:48:23,400
or rooting around it.

1326
00:48:23,400 --> 00:48:27,640
And routing around it is the signal that the path itself needs attention,

1327
00:48:27,640 --> 00:48:29,800
not that the developers need more restrictions.

1328
00:48:29,800 --> 00:48:33,720
The cultural shift this requires from security teams is the hardest part of the transition

1329
00:48:33,720 --> 00:48:35,160
and it's worth naming directly.

1330
00:48:35,160 --> 00:48:37,480
The job changes from reviewing individual deployments

1331
00:48:37,480 --> 00:48:40,840
to designing the system that makes individual reviews unnecessary.

1332
00:48:40,840 --> 00:48:44,680
That shift requires relinquishing a form of visibility that felt like control

1333
00:48:44,680 --> 00:48:48,280
in exchange for a structural model that produces better outcomes at scale.

1334
00:48:48,280 --> 00:48:50,280
The teams that have made it don't want to go back.

1335
00:48:50,280 --> 00:48:54,120
EntraID governance, the identity control plane,

1336
00:48:54,120 --> 00:48:56,440
the Golden Path governs what developers can build,

1337
00:48:56,440 --> 00:48:59,640
the policy engine governs what resources are allowed to exist,

1338
00:48:59,640 --> 00:49:01,800
PM governs when privileged humans can act.

1339
00:49:01,800 --> 00:49:05,480
But none of those mechanisms answer the question that sits underneath all of them.

1340
00:49:05,480 --> 00:49:07,640
Who should have access to what right now?

1341
00:49:07,640 --> 00:49:11,480
Given where they are in their role and their relationship with the organization.

1342
00:49:11,480 --> 00:49:15,960
That question asked continuously, answered accurately and enforced automatically

1343
00:49:15,960 --> 00:49:18,120
is what EntraID governance is built for.

1344
00:49:18,120 --> 00:49:21,080
Most organizations treat EntraID governance as a feature set

1345
00:49:21,080 --> 00:49:22,840
rather than an architectural layer.

1346
00:49:22,840 --> 00:49:27,000
They turn on access reviews when an auditor asks for evidence of recertification.

1347
00:49:27,000 --> 00:49:31,560
They configure a life cycle workflow when HR complains that offboarding takes too long.

1348
00:49:31,560 --> 00:49:34,440
They use entitlement management for a specific application

1349
00:49:34,440 --> 00:49:35,960
because someone read a blog post.

1350
00:49:35,960 --> 00:49:39,800
These are isolated implementations of something that only delivers its full value

1351
00:49:39,800 --> 00:49:41,960
when it operates as a coherent system.

1352
00:49:41,960 --> 00:49:44,920
A control plane that sits above RBAC, above PM,

1353
00:49:44,920 --> 00:49:47,080
and above every individual access decision.

1354
00:49:47,080 --> 00:49:49,640
It determines whether the access model stays coherent

1355
00:49:49,640 --> 00:49:51,720
as the organization changes around it.

1356
00:49:51,720 --> 00:49:54,280
Four components work together to make that possible.

1357
00:49:54,280 --> 00:49:58,680
Life cycle workflows automate the identity events that happen when someone joins,

1358
00:49:58,680 --> 00:50:01,080
moves within, or leaves the organization.

1359
00:50:01,080 --> 00:50:05,240
When a new developer joins a platform team, the workflow triggers automatically.

1360
00:50:05,240 --> 00:50:07,080
Account creation, group membership assignment,

1361
00:50:07,080 --> 00:50:09,480
and access package provisioning all happen without a ticket.

1362
00:50:09,480 --> 00:50:12,280
When that developer moves to a different team three months later,

1363
00:50:12,280 --> 00:50:15,720
the mover workflow removes the access that was relevant to the old role

1364
00:50:15,720 --> 00:50:17,800
and provisions what the new role requires.

1365
00:50:17,800 --> 00:50:21,400
So when they leave the organization, the lever workflow revokes everything.

1366
00:50:21,400 --> 00:50:24,840
Group memberships, application access, and Azure RBAC entitlements.

1367
00:50:24,840 --> 00:50:26,360
Before the end of their last day,

1368
00:50:26,360 --> 00:50:29,080
the human life cycle drives the access model automatically.

1369
00:50:29,080 --> 00:50:30,360
No manual cleanup queue.

1370
00:50:30,360 --> 00:50:31,960
No, I'll get to it next week.

1371
00:50:31,960 --> 00:50:34,120
No orphaned access sitting in the environment

1372
00:50:34,120 --> 00:50:36,120
because the off-boarding ticket got lost.

1373
00:50:36,120 --> 00:50:38,360
Entitlement management addresses a different problem.

1374
00:50:38,360 --> 00:50:39,640
How do you make governed access

1375
00:50:39,640 --> 00:50:41,560
"requestable" without making it ungoverned?

1376
00:50:41,560 --> 00:50:43,960
Access packages bundle the things a person needs

1377
00:50:43,960 --> 00:50:45,960
for a specific role or project.

1378
00:50:45,960 --> 00:50:48,680
EntraID group memberships, application assignments,

1379
00:50:48,680 --> 00:50:50,280
and Azure RBAC roles.

1380
00:50:50,280 --> 00:50:53,480
Into a single, requestable unit with defined approval workflows,

1381
00:50:53,480 --> 00:50:55,960
eligibility criteria, and automatic exploration.

1382
00:50:55,960 --> 00:50:58,840
A developer who needs access to a production monitoring dashboard

1383
00:50:58,840 --> 00:51:01,560
a specific key vault, and the relevant security group

1384
00:51:01,560 --> 00:51:04,440
doesn't submit three separate tickets to three different teams.

1385
00:51:04,440 --> 00:51:07,400
They request one access package from a self-service portal.

1386
00:51:07,400 --> 00:51:10,120
An approver reviews the request against defined criteria.

1387
00:51:10,120 --> 00:51:12,520
The access is granted with a built-in expiration.

1388
00:51:12,520 --> 00:51:15,240
90 days, six months, whatever the package policy defines.

1389
00:51:15,240 --> 00:51:18,120
When it expires, it's gone unless the person requests renewal

1390
00:51:18,120 --> 00:51:20,200
and the approver reauthorizes.

1391
00:51:20,200 --> 00:51:22,040
Entitlement management makes access,

1392
00:51:22,040 --> 00:51:25,160
requestable, and time-bound by default, not by exception.

1393
00:51:25,160 --> 00:51:26,680
Access reviews are the ongoing

1394
00:51:26,680 --> 00:51:29,720
re-certification mechanism that keeps the model honest.

1395
00:51:29,720 --> 00:51:31,880
Every quarter, group owners, application owners,

1396
00:51:31,880 --> 00:51:34,040
and role owners receive review tasks.

1397
00:51:34,040 --> 00:51:36,200
They have to decide if this person still needs membership

1398
00:51:36,200 --> 00:51:39,000
in this group, or if this RBAC assignment is still appropriate

1399
00:51:39,000 --> 00:51:40,360
for this person's current role.

1400
00:51:40,360 --> 00:51:43,160
They also have to determine if this access package assignment

1401
00:51:43,160 --> 00:51:44,280
should be renewed.

1402
00:51:44,280 --> 00:51:46,920
The review surface, the drift, that accumulates even

1403
00:51:46,920 --> 00:51:48,360
in well-governed environments.

1404
00:51:48,360 --> 00:51:51,080
People who changed roles but retained old access,

1405
00:51:51,080 --> 00:51:52,920
assignments that were supposed to be temporary

1406
00:51:52,920 --> 00:51:54,120
but never expired.

1407
00:51:54,120 --> 00:51:56,200
An entitlements that made sense six months ago,

1408
00:51:56,200 --> 00:51:58,280
but are now broader than necessary.

1409
00:51:58,280 --> 00:52:01,320
The review process isn't just evidence generation for auditors.

1410
00:52:01,320 --> 00:52:03,560
It's the cleanup mechanism that keeps the access model

1411
00:52:03,560 --> 00:52:06,520
continuously calibrated rather than periodically corrected.

1412
00:52:06,520 --> 00:52:08,360
Here's where most governance programs have a gap

1413
00:52:08,360 --> 00:52:09,480
they haven't closed yet.

1414
00:52:09,480 --> 00:52:11,240
Service principles and managed identities

1415
00:52:11,240 --> 00:52:13,080
are identity actors in your tenant.

1416
00:52:13,080 --> 00:52:16,280
They access resources, call APIs, read mailboxes,

1417
00:52:16,280 --> 00:52:17,320
and write data.

1418
00:52:17,320 --> 00:52:19,960
But they almost never appear in access review campaigns.

1419
00:52:19,960 --> 00:52:22,200
The human identity governance model gets applied

1420
00:52:22,200 --> 00:52:23,400
to users and groups,

1421
00:52:23,400 --> 00:52:25,160
the workload identity population,

1422
00:52:25,160 --> 00:52:26,920
which in most large tenants is larger

1423
00:52:26,920 --> 00:52:28,680
and carries more sensitive permissions

1424
00:52:28,680 --> 00:52:30,040
than the human population.

1425
00:52:30,040 --> 00:52:33,160
Operates outside the governance life cycle entirely,

1426
00:52:33,160 --> 00:52:35,560
including workload identities and access reviews,

1427
00:52:35,560 --> 00:52:36,840
applying ownership requirements

1428
00:52:36,840 --> 00:52:38,760
through the same entitlement management model

1429
00:52:38,760 --> 00:52:41,240
and treating a managed identities role assignments

1430
00:52:41,240 --> 00:52:44,200
with the same recertification rigor as a humans.

1431
00:52:44,200 --> 00:52:45,800
That's the closure that transforms

1432
00:52:45,800 --> 00:52:47,800
a partial identity governance program

1433
00:52:47,800 --> 00:52:49,000
into a complete one.

1434
00:52:49,000 --> 00:52:50,920
The trust model EntraID governance enables

1435
00:52:50,920 --> 00:52:51,960
isn't a philosophy.

1436
00:52:51,960 --> 00:52:53,480
It's an operational state.

1437
00:52:53,480 --> 00:52:54,920
Access granted when needed,

1438
00:52:54,920 --> 00:52:56,280
scope to what's required

1439
00:52:56,280 --> 00:52:58,120
and removed when the need ends.

1440
00:52:58,120 --> 00:53:00,120
For every identity in the tenant,

1441
00:53:00,120 --> 00:53:02,040
human and workload alike,

1442
00:53:02,040 --> 00:53:03,480
purview and azure policy,

1443
00:53:03,480 --> 00:53:05,720
two control planes, one architecture,

1444
00:53:05,720 --> 00:53:07,640
one of the most common architectural mistakes

1445
00:53:07,640 --> 00:53:09,880
in Microsoft environments is treating purview

1446
00:53:09,880 --> 00:53:12,200
and azure policy as competing tools.

1447
00:53:12,200 --> 00:53:13,560
People often think they have to choose

1448
00:53:13,560 --> 00:53:15,080
which one governs compliance.

1449
00:53:15,080 --> 00:53:17,400
The confusion makes sense because both have dashboards,

1450
00:53:17,400 --> 00:53:19,000
both use policy definitions

1451
00:53:19,000 --> 00:53:20,680
and both spit out compliance reports.

1452
00:53:20,680 --> 00:53:21,720
But in reality,

1453
00:53:21,720 --> 00:53:23,320
they answer fundamentally different questions

1454
00:53:23,320 --> 00:53:24,680
about different surfaces,

1455
00:53:24,680 --> 00:53:26,200
conflating them creates gaps

1456
00:53:26,200 --> 00:53:29,080
in exactly the places attackers and auditors look first,

1457
00:53:29,080 --> 00:53:31,080
azure policy governs infrastructure state.

1458
00:53:31,080 --> 00:53:33,240
The question it answers continuously is,

1459
00:53:33,240 --> 00:53:36,040
are my resources configured the way I defined them?

1460
00:53:36,040 --> 00:53:37,960
You use it to check if keywolds are using

1461
00:53:37,960 --> 00:53:41,080
RBAC authorization or if storage accounts are encrypted

1462
00:53:41,080 --> 00:53:42,760
with customer managed keys.

1463
00:53:42,760 --> 00:53:45,320
It monitors if diagnostic logs flow to the right workspace

1464
00:53:45,320 --> 00:53:47,320
and a virtual network's use private endpoints.

1465
00:53:47,320 --> 00:53:49,160
Every resource in your estate is evaluated

1466
00:53:49,160 --> 00:53:51,320
against these rules on an ongoing basis.

1467
00:53:51,320 --> 00:53:53,320
Non-compliance triggers an audit finding,

1468
00:53:53,320 --> 00:53:54,600
a remediation task,

1469
00:53:54,600 --> 00:53:56,920
or a deployment block depending on your setup.

1470
00:53:56,920 --> 00:53:59,080
azure policy doesn't care about the content

1471
00:53:59,080 --> 00:54:00,600
moving through those resources.

1472
00:54:00,600 --> 00:54:02,200
It only cares about the configuration

1473
00:54:02,200 --> 00:54:03,640
of the resources themselves.

1474
00:54:03,640 --> 00:54:05,080
Purview governs data behavior.

1475
00:54:05,080 --> 00:54:07,560
The question it answers is different.

1476
00:54:07,560 --> 00:54:10,680
Is sensitive data being handled the way my policies require?

1477
00:54:10,680 --> 00:54:12,280
It looks for credit card numbers being

1478
00:54:12,280 --> 00:54:13,800
emailed to external domains

1479
00:54:13,800 --> 00:54:15,800
or files marked as highly confidential

1480
00:54:15,800 --> 00:54:17,960
being copied to unmanaged devices.

1481
00:54:17,960 --> 00:54:19,960
It checks if retention labels are applied

1482
00:54:19,960 --> 00:54:22,440
to content that falls within a regulatory scope.

1483
00:54:22,440 --> 00:54:25,080
Purview operates at the data layer by inspecting content

1484
00:54:25,080 --> 00:54:27,560
and enforcing movement restrictions based on what the data is

1485
00:54:27,560 --> 00:54:29,320
not where the infrastructure sits.

1486
00:54:29,320 --> 00:54:32,280
It can't tell you if your key vault has purge protection enabled.

1487
00:54:32,280 --> 00:54:35,160
Likewise, azure policy can't tell you if a SharePoint user

1488
00:54:35,160 --> 00:54:37,800
just exfiltrated a document containing health records.

1489
00:54:37,800 --> 00:54:40,920
The shared foundation underneath both is Microsoft EntraID.

1490
00:54:40,920 --> 00:54:44,520
Every enforcement decision both tools make ties back to an identity.

1491
00:54:44,520 --> 00:54:47,240
The RBAC assignments, azure policy evaluates

1492
00:54:47,240 --> 00:54:49,080
are EntraID principles

1493
00:54:49,080 --> 00:54:51,560
and the DLP policies purview enforcers

1494
00:54:51,560 --> 00:54:54,920
are scoped to EntraID users, groups and devices.

1495
00:54:54,920 --> 00:54:57,960
Classification labels applied by purview travel with content

1496
00:54:57,960 --> 00:55:01,160
through the same identity-authenticated sessions that Entra governs.

1497
00:55:01,160 --> 00:55:03,560
When you design these control planes together rather than

1498
00:55:03,560 --> 00:55:05,960
independently that shared identity foundation

1499
00:55:05,960 --> 00:55:07,640
becomes a coordination surface.

1500
00:55:07,640 --> 00:55:10,040
It's the place where decisions made at the infrastructure layer

1501
00:55:10,040 --> 00:55:12,280
and the data layer reinforce each other

1502
00:55:12,280 --> 00:55:13,960
instead of operating in separate silos,

1503
00:55:13,960 --> 00:55:16,920
where they intersect operationally is worth being specific about

1504
00:55:16,920 --> 00:55:19,400
because that intersection has become more concrete recently?

1505
00:55:19,400 --> 00:55:22,520
azure policy can enforce that azure rights management encryption

1506
00:55:22,520 --> 00:55:25,400
is applied to specific workloads so that certain storage accounts

1507
00:55:25,400 --> 00:55:28,280
or communication channels use RMS protected encryption.

1508
00:55:28,280 --> 00:55:33,480
Purview endpoint DLP, as of the April 2026 rollout,

1509
00:55:33,480 --> 00:55:35,960
can now classify those protected office documents

1510
00:55:35,960 --> 00:55:39,000
and apply DLP policy actions to them directly on endpoints.

1511
00:55:39,000 --> 00:55:39,880
That's a closed loop.

1512
00:55:39,880 --> 00:55:41,880
azure policy defines the encryption requirement

1513
00:55:41,880 --> 00:55:43,240
at the infrastructure layer

1514
00:55:43,240 --> 00:55:45,480
while purview enforces data handling policy

1515
00:55:45,480 --> 00:55:48,360
on the encrypted content that infrastructure produces.

1516
00:55:48,360 --> 00:55:50,680
One control plane creates the governed environment,

1517
00:55:50,680 --> 00:55:52,520
the other governs what happens inside it.

1518
00:55:52,520 --> 00:55:55,800
The M365 compliance center integration with azure policy

1519
00:55:55,800 --> 00:55:57,320
has moved in the same direction.

1520
00:55:57,320 --> 00:55:59,960
azure policy's regulatory compliance initiatives

1521
00:55:59,960 --> 00:56:03,080
now include M365 related control mappings.

1522
00:56:03,080 --> 00:56:05,480
The A-Cat M365's third initiative definition

1523
00:56:05,480 --> 00:56:08,200
in the public azure policy repository is evidence

1524
00:56:08,200 --> 00:56:10,360
that Microsoft is actively bridging the gap

1525
00:56:10,360 --> 00:56:13,880
between infrastructure reporting and M365 requirements.

1526
00:56:13,880 --> 00:56:15,400
It's not a full architectural merge

1527
00:56:15,400 --> 00:56:16,920
and you shouldn't design as if it is

1528
00:56:16,920 --> 00:56:19,160
but the convergence is real and it's directional.

1529
00:56:19,160 --> 00:56:21,880
The practical design principle is simple.

1530
00:56:21,880 --> 00:56:23,720
Build your azure policy baseline

1531
00:56:23,720 --> 00:56:26,600
and your purview DLP strategy in the same design session.

1532
00:56:26,600 --> 00:56:28,600
Do not treat them as separate work streams

1533
00:56:28,600 --> 00:56:30,200
owned by separate teams.

1534
00:56:30,200 --> 00:56:32,440
The infrastructure decisions as your policy enforces

1535
00:56:32,440 --> 00:56:35,480
directly shape the surface purview DLP operates against.

1536
00:56:35,480 --> 00:56:38,120
This includes which services use RMS encryption

1537
00:56:38,120 --> 00:56:40,760
which networks restrict data exfiltration parts

1538
00:56:40,760 --> 00:56:43,880
and which logging configurations feed your correlation queries.

1539
00:56:43,880 --> 00:56:45,720
Design them together and they amplify each other.

1540
00:56:45,720 --> 00:56:49,400
Design them in isolation and you'll spend months discovering the gaps between them.

1541
00:56:49,400 --> 00:56:51,560
Zero trust as the operating principle.

1542
00:56:51,560 --> 00:56:53,960
Every architectural decision covered in this episode

1543
00:56:53,960 --> 00:56:55,560
was made inside a framework.

1544
00:56:55,560 --> 00:56:58,600
Policy enforcement, ABAC design, PM activation,

1545
00:56:58,600 --> 00:57:01,080
managed identity scoping, key vault configuration,

1546
00:57:01,080 --> 00:57:03,960
and enter ID governance all follow a specific logic.

1547
00:57:03,960 --> 00:57:05,640
That framework isn't a product you buy

1548
00:57:05,640 --> 00:57:07,480
or a vendor category you evaluate.

1549
00:57:07,480 --> 00:57:09,320
It's an operating principle that determines

1550
00:57:09,320 --> 00:57:12,200
how you reason about every governance decision before you make it.

1551
00:57:12,200 --> 00:57:13,640
Zero trust is that principle.

1552
00:57:13,640 --> 00:57:16,280
It matters here because it's the only model that makes compliance

1553
00:57:16,280 --> 00:57:19,800
as code coherent rather than just technically sophisticated.

1554
00:57:19,800 --> 00:57:21,560
The three principles are well known.

1555
00:57:21,560 --> 00:57:25,320
Verify explicitly, use least privilege, and assume breach.

1556
00:57:25,320 --> 00:57:27,080
What's less understood is what they mean

1557
00:57:27,080 --> 00:57:29,080
when you translate them from a security philosophy

1558
00:57:29,080 --> 00:57:33,320
into daily operational decisions across an Azure and M365 estate.

1559
00:57:33,320 --> 00:57:36,600
Verify explicitly means trust is never inherited from context.

1560
00:57:36,600 --> 00:57:39,240
A request coming from inside your vnet doesn't get trust

1561
00:57:39,240 --> 00:57:40,760
just because it's inside your vnet.

1562
00:57:40,760 --> 00:57:43,400
A workload running on a trusted VM doesn't get trust

1563
00:57:43,400 --> 00:57:44,920
because the VM is trusted.

1564
00:57:44,920 --> 00:57:48,120
Every access request carries its own authentication burden.

1565
00:57:48,120 --> 00:57:50,680
For human access that means MFA, device compliance,

1566
00:57:50,680 --> 00:57:52,600
and conditional access evaluation.

1567
00:57:52,600 --> 00:57:54,680
For workload access it means managed identities

1568
00:57:54,680 --> 00:57:56,840
authenticating through enter ID with short-lived,

1569
00:57:56,840 --> 00:57:59,880
cryptographically signed tokens for every service to service call.

1570
00:57:59,880 --> 00:58:01,560
The trust is verified at each hop.

1571
00:58:01,560 --> 00:58:04,040
No call inherits permission from the previous one.

1572
00:58:04,040 --> 00:58:05,880
The identity model is the control plane,

1573
00:58:05,880 --> 00:58:07,320
not the network topology.

1574
00:58:07,320 --> 00:58:08,920
Usually's privilege is the principle

1575
00:58:08,920 --> 00:58:12,120
that shaped every scoping decision discussed in this episode.

1576
00:58:12,120 --> 00:58:15,000
You apply our back assignments at the narrowest viable scope

1577
00:58:15,000 --> 00:58:17,640
and target managed identity roles at specific resources

1578
00:58:17,640 --> 00:58:19,560
rather than entire subscriptions.

1579
00:58:19,560 --> 00:58:21,880
PM activation windows are measured in hours

1580
00:58:21,880 --> 00:58:24,280
rather than weeks, and key vault secret access

1581
00:58:24,280 --> 00:58:27,480
is granted to specific secrets rather than entire vaults.

1582
00:58:27,480 --> 00:58:29,880
Entitlement management packages bundle exactly

1583
00:58:29,880 --> 00:58:32,440
what a role requires and expire automatically.

1584
00:58:32,440 --> 00:58:35,240
These privilege isn't a one-time configuration exercise.

1585
00:58:35,240 --> 00:58:37,000
It's a continuous design pressure applied

1586
00:58:37,000 --> 00:58:38,600
to every permission decision.

1587
00:58:38,600 --> 00:58:40,520
It is resisted by convenience at every turn

1588
00:58:40,520 --> 00:58:43,400
and only sustain through automation and ongoing review.

1589
00:58:43,400 --> 00:58:45,640
Assume breach is the principle

1590
00:58:45,640 --> 00:58:48,840
that changes how you think about the value of all the other controls.

1591
00:58:48,840 --> 00:58:50,360
Don't design a governance architecture

1592
00:58:50,360 --> 00:58:52,360
on the assumption that attackers won't get in.

1593
00:58:52,360 --> 00:58:54,680
Design it on the assumption that they already have

1594
00:58:54,680 --> 00:58:57,080
and then ask what can they reach from here.

1595
00:58:57,080 --> 00:58:58,840
PM eliminates standing access

1596
00:58:58,840 --> 00:59:00,840
so that a compromised account credential

1597
00:59:00,840 --> 00:59:03,800
produces an eligible assignment instead of an active one.

1598
00:59:03,800 --> 00:59:05,800
Environment scoped managed identities limit

1599
00:59:05,800 --> 00:59:08,120
what an attacker can do with a compromised workloads

1600
00:59:08,120 --> 00:59:11,000
token to the blast radius of that specific environment.

1601
00:59:11,000 --> 00:59:13,800
Private endpoints and deny by default NSG rules

1602
00:59:13,800 --> 00:59:16,920
mean that lateral movement inside a compromised network encounters

1603
00:59:16,920 --> 00:59:19,320
real resistance rather than flat trust.

1604
00:59:19,320 --> 00:59:21,640
Every layer is designed to contain damage.

1605
00:59:21,640 --> 00:59:23,320
There are two developments worth naming

1606
00:59:23,320 --> 00:59:26,120
that extend the zero trust model into territory.

1607
00:59:26,120 --> 00:59:28,040
Most organizations haven't governed yet.

1608
00:59:28,040 --> 00:59:29,880
The first is workload identity federation.

1609
00:59:29,880 --> 00:59:32,680
Managed identities can now serve as federated credentials

1610
00:59:32,680 --> 00:59:34,840
for entry applications across tenant boundaries.

1611
00:59:34,840 --> 00:59:36,760
A workload in one tenant can authenticate

1612
00:59:36,760 --> 00:59:39,400
to resources in another tenant using its managed identity

1613
00:59:39,400 --> 00:59:40,200
as the credential.

1614
00:59:40,200 --> 00:59:41,480
There are no shared secrets

1615
00:59:41,480 --> 00:59:43,960
and no certificates pass between organizations.

1616
00:59:43,960 --> 00:59:45,560
The trust relationship is expressed

1617
00:59:45,560 --> 00:59:47,960
as an identity federation governed by Entra

1618
00:59:47,960 --> 00:59:50,040
with every cross tenant authentication logged.

1619
00:59:50,040 --> 00:59:52,200
This is cross tenant trust without the attack surface

1620
00:59:52,200 --> 00:59:53,720
that shared credentials create.

1621
00:59:53,720 --> 00:59:55,080
The second is the network layer

1622
00:59:55,080 --> 00:59:57,800
which often gets ignored in identity heavy conversations.

1623
00:59:57,800 --> 00:59:59,240
You need a hub and spoke topology

1624
00:59:59,240 --> 01:00:00,680
with Azure Firewall in the hub

1625
01:00:00,680 --> 01:00:03,720
and per application vNets with subnet level segmentation.

1626
01:00:03,720 --> 01:00:06,520
NSG baselines should be set to deny by default

1627
01:00:06,520 --> 01:00:08,280
with explicit allow rules scoped

1628
01:00:08,280 --> 01:00:11,320
to the actual communication patterns each service requires.

1629
01:00:11,320 --> 01:00:13,320
Use private endpoints for every pass service

1630
01:00:13,320 --> 01:00:16,280
that supports them including Key Vault, Storage, SQL,

1631
01:00:16,280 --> 01:00:17,160
and Service Bus.

1632
01:00:17,160 --> 01:00:19,960
This removes those services from any public network exposure

1633
01:00:19,960 --> 01:00:20,840
entirely.

1634
01:00:20,840 --> 01:00:23,320
The network layer doesn't replace the identity layer.

1635
01:00:23,320 --> 01:00:26,600
It reduces the blast radius when the identity layer is penetrated

1636
01:00:26,600 --> 01:00:28,760
which assume breach tells you to plan for.

1637
01:00:28,760 --> 01:00:30,520
Zero trust isn't a state you reach.

1638
01:00:30,520 --> 01:00:31,800
It's a continuous posture.

1639
01:00:31,800 --> 01:00:34,200
It is a direction you orient every architectural decision

1640
01:00:34,200 --> 01:00:35,960
toward knowing you're never fully there

1641
01:00:35,960 --> 01:00:37,000
but getting measurably close

1642
01:00:37,000 --> 01:00:39,080
with each control you implement correctly.

1643
01:00:39,080 --> 01:00:42,680
Azure Policy, PIM, Managed Identities, Key Vault,

1644
01:00:42,680 --> 01:00:45,880
and EntraID governance are not just marketing materials.

1645
01:00:45,880 --> 01:00:48,120
They are the technical implementation of that posture.

1646
01:00:48,120 --> 01:00:50,200
They are built into the infrastructure itself

1647
01:00:50,200 --> 01:00:52,440
and run continuously without waiting for a human

1648
01:00:52,440 --> 01:00:54,200
to decide its time to check.

1649
01:00:54,200 --> 01:00:56,760
Monitoring drift detection and continuous compliance.

1650
01:00:56,760 --> 01:00:59,080
Your compliance dashboard is not a compliance program

1651
01:00:59,080 --> 01:01:00,920
that distinction matters more than it sounds.

1652
01:01:00,920 --> 01:01:03,320
Most organizations build an elaborate infrastructure

1653
01:01:03,320 --> 01:01:05,400
just to generate reports that nobody looks at.

1654
01:01:05,400 --> 01:01:07,400
They produce the data, they file it away,

1655
01:01:07,400 --> 01:01:09,640
and then they wait for the next reporting cycle.

1656
01:01:09,640 --> 01:01:11,320
A dashboard that refreshes once a day

1657
01:01:11,320 --> 01:01:13,960
and gets reviewed once a quarter is just audit theater.

1658
01:01:13,960 --> 01:01:15,720
It might have better graphics than a spreadsheet

1659
01:01:15,720 --> 01:01:16,920
but it's still theater.

1660
01:01:16,920 --> 01:01:19,320
The posture it shows you is a historical snapshot.

1661
01:01:19,320 --> 01:01:21,240
It's a picture of a moment that has already passed.

1662
01:01:21,240 --> 01:01:23,720
Your environment has drifted since that picture was taken.

1663
01:01:23,720 --> 01:01:25,400
You just don't know where it happened yet.

1664
01:01:25,400 --> 01:01:28,120
Continuous compliance means the system monitors itself.

1665
01:01:28,120 --> 01:01:31,400
It means that when the environment deviates from the state you defined,

1666
01:01:31,400 --> 01:01:33,320
it generates a signal automatically.

1667
01:01:33,320 --> 01:01:35,720
Those signals flow into your alerting pipelines

1668
01:01:35,720 --> 01:01:37,800
and then someone or something responds

1669
01:01:37,800 --> 01:01:40,200
before that deviation turns into an actual incident.

1670
01:01:40,200 --> 01:01:42,600
The monitoring architecture isn't a separate program

1671
01:01:42,600 --> 01:01:44,280
you layer on top of your governance.

1672
01:01:44,280 --> 01:01:46,040
It's built into the same infrastructure.

1673
01:01:46,040 --> 01:01:47,400
It draws from the same sources.

1674
01:01:47,400 --> 01:01:49,400
It runs the same continuous evaluation loop

1675
01:01:49,400 --> 01:01:51,560
that your policies run against your resources.

1676
01:01:51,560 --> 01:01:54,680
Three log sources form the backbone of a complete audit trail.

1677
01:01:54,680 --> 01:01:56,360
First, you have enter a sign in logs.

1678
01:01:56,360 --> 01:01:58,680
These capture every authentication event

1679
01:01:58,680 --> 01:02:00,440
for both humans and workloads.

1680
01:02:00,440 --> 01:02:02,440
They tell you which identity authenticated,

1681
01:02:02,440 --> 01:02:04,680
where they came from, which resource they hit,

1682
01:02:04,680 --> 01:02:05,960
and what the result was.

1683
01:02:05,960 --> 01:02:07,960
Second, you have Key Vault diagnostic logs.

1684
01:02:07,960 --> 01:02:11,000
These capture every data plane operation against your vaults.

1685
01:02:11,000 --> 01:02:13,080
Every time a secret is read, a key is used

1686
01:02:13,080 --> 01:02:15,320
or a certificate is retrieved, it's recorded here.

1687
01:02:15,320 --> 01:02:16,920
It even tracks the failed attempts.

1688
01:02:16,920 --> 01:02:18,600
Third, you have Azure Activity Logs.

1689
01:02:18,600 --> 01:02:19,960
These tell the control plane stories.

1690
01:02:19,960 --> 01:02:21,240
They show who created a resource,

1691
01:02:21,240 --> 01:02:22,760
who modified a role assignment,

1692
01:02:22,760 --> 01:02:24,040
and who deleted a vault.

1693
01:02:24,040 --> 01:02:27,000
Each source answers a different layer of the governance question.

1694
01:02:27,000 --> 01:02:28,760
But none of them can answer it alone.

1695
01:02:28,760 --> 01:02:30,760
The value of connecting these logs becomes clear

1696
01:02:30,760 --> 01:02:32,760
when you look at a real world scenario.

1697
01:02:32,760 --> 01:02:35,800
Imagine a PIM activation happens at 2am on a Saturday.

1698
01:02:35,800 --> 01:02:37,480
The enter sign in log records it.

1699
01:02:37,480 --> 01:02:39,320
You see which account activated which role,

1700
01:02:39,320 --> 01:02:40,520
the scope they targeted,

1701
01:02:40,520 --> 01:02:42,120
and the justification they typed in.

1702
01:02:42,120 --> 01:02:43,080
30 minutes later,

1703
01:02:43,080 --> 01:02:45,560
the Azure Activity Log shows a new role assignment

1704
01:02:45,560 --> 01:02:46,920
on a production subscription.

1705
01:02:46,920 --> 01:02:49,480
That assignment was made by the account that just activated.

1706
01:02:49,480 --> 01:02:50,600
20 minutes after that,

1707
01:02:50,600 --> 01:02:54,280
the Key Vault diagnostic logs show a massive spike in secret reads.

1708
01:02:54,280 --> 01:02:55,480
This is coming from an identity

1709
01:02:55,480 --> 01:02:57,160
that doesn't normally touch that vault.

1710
01:02:57,160 --> 01:03:00,200
In isolation, you could explain each of those events away.

1711
01:03:00,200 --> 01:03:01,640
But together, they form a pattern

1712
01:03:01,640 --> 01:03:04,440
that answers the one question regulators always ask.

1713
01:03:04,440 --> 01:03:06,040
They want to know who had privileged access

1714
01:03:06,040 --> 01:03:07,480
if they used it, what they touched,

1715
01:03:07,480 --> 01:03:09,080
and if any of it was authorized.

1716
01:03:09,080 --> 01:03:10,680
Correlation gives you that answer.

1717
01:03:10,680 --> 01:03:12,760
SiloDlog Review just gives you fragments.

1718
01:03:12,760 --> 01:03:14,520
The Entertainment Governance Preview

1719
01:03:14,520 --> 01:03:16,280
moves this model into territory.

1720
01:03:16,280 --> 01:03:18,200
Most companies haven't monitored before.

1721
01:03:18,200 --> 01:03:19,720
It uses configuration as code

1722
01:03:19,720 --> 01:03:22,280
for over 200 intra-resource types.

1723
01:03:22,280 --> 01:03:24,600
This includes your conditional access policies,

1724
01:03:24,600 --> 01:03:26,040
your authentication methods,

1725
01:03:26,040 --> 01:03:28,200
and your external collaboration settings.

1726
01:03:28,200 --> 01:03:30,920
Everything that defines how your identity plane behaves

1727
01:03:30,920 --> 01:03:32,280
is captured as a baseline.

1728
01:03:32,280 --> 01:03:34,680
The system scans for drift on a six-hour cycle.

1729
01:03:34,680 --> 01:03:37,880
When your tenant configuration moves away from that defined state,

1730
01:03:37,880 --> 01:03:39,400
you know about it within hours.

1731
01:03:39,400 --> 01:03:41,800
You don't find out because in order to ask the question,

1732
01:03:41,800 --> 01:03:44,280
you don't find out because an incident exposed the gap.

1733
01:03:44,280 --> 01:03:47,080
You know, because the system is constantly comparing the current state

1734
01:03:47,080 --> 01:03:48,680
to your codified baseline.

1735
01:03:48,680 --> 01:03:50,600
It's the same principle as policy compliance scanning

1736
01:03:50,600 --> 01:03:52,920
but it's applied to the identity control plane itself.

1737
01:03:52,920 --> 01:03:56,440
Our back drift detection follows the same pattern for your role assignments.

1738
01:03:56,440 --> 01:03:59,640
You should export your role assignments to get on a regular schedule.

1739
01:03:59,640 --> 01:04:03,160
Doing this daily is practical but for high sensitivity subscriptions,

1740
01:04:03,160 --> 01:04:04,280
hourly is better.

1741
01:04:04,280 --> 01:04:05,960
If an assignment appears in the environment

1742
01:04:05,960 --> 01:04:07,720
that doesn't have a match in your code,

1743
01:04:07,720 --> 01:04:08,760
it triggers a review.

1744
01:04:08,760 --> 01:04:10,120
This isn't a manual check.

1745
01:04:10,120 --> 01:04:12,840
It's an automated comparison that flags the discrepancy

1746
01:04:12,840 --> 01:04:14,760
and creates a remediation task.

1747
01:04:14,760 --> 01:04:16,200
The code is the source of truth.

1748
01:04:16,200 --> 01:04:18,200
Anything that doesn't match it is drift

1749
01:04:18,200 --> 01:04:19,800
and drift requires an explanation

1750
01:04:19,800 --> 01:04:21,800
before it can become the accepted state.

1751
01:04:21,800 --> 01:04:24,520
The alert patterns that actually matter aren't the obvious ones.

1752
01:04:24,520 --> 01:04:27,000
If a workload identity usually makes five reads an hour

1753
01:04:27,000 --> 01:04:29,560
and suddenly makes five hundred, that's worth an alert.

1754
01:04:29,560 --> 01:04:32,680
If a role is activated through PIM outside of business hours

1755
01:04:32,680 --> 01:04:34,360
when it's never been used that way before,

1756
01:04:34,360 --> 01:04:35,400
that's worth an alert.

1757
01:04:35,400 --> 01:04:37,640
If a role assignment appears at a subscription scope

1758
01:04:37,640 --> 01:04:39,560
and bypasses your standard workflow,

1759
01:04:39,560 --> 01:04:40,680
that's worth an alert.

1760
01:04:40,680 --> 01:04:42,680
These patterns don't require exotic logic.

1761
01:04:42,680 --> 01:04:44,840
They just require you to know what normal looks like.

1762
01:04:44,840 --> 01:04:46,840
You baseline the expected behavior,

1763
01:04:46,840 --> 01:04:49,080
then you build alerts against the deviations.

1764
01:04:49,080 --> 01:04:51,320
The governance architecture you've already built

1765
01:04:51,320 --> 01:04:52,680
defines what is normal.

1766
01:04:52,680 --> 01:04:55,640
The monitoring layer just watches for the moment things diverge.

1767
01:04:55,640 --> 01:04:58,520
Because detection without response is just expensive logging.

1768
01:04:58,520 --> 01:05:01,320
Remediation exceptions and the governance life cycle.

1769
01:05:01,320 --> 01:05:03,160
Detection tells you something is wrong.

1770
01:05:03,160 --> 01:05:04,680
What happens next is what matters.

1771
01:05:04,680 --> 01:05:07,400
It determines whether your governance architecture actually holds

1772
01:05:07,400 --> 01:05:09,400
or if it slowly dissolves into a collection

1773
01:05:09,400 --> 01:05:12,280
of documented intentions and undocumented reality.

1774
01:05:12,280 --> 01:05:13,960
You have to start with exceptions.

1775
01:05:13,960 --> 01:05:16,520
This is where most governance programs quietly fail.

1776
01:05:16,520 --> 01:05:18,200
The goal isn't to have zero exceptions

1777
01:05:18,200 --> 01:05:19,000
that's impossible.

1778
01:05:19,000 --> 01:05:20,920
Migrations need temporary access.

1779
01:05:20,920 --> 01:05:24,040
Incident response needs permissions that aren't in the standard catalogue.

1780
01:05:24,040 --> 01:05:26,680
Regulatory requirements create legitimate carve-outs.

1781
01:05:26,680 --> 01:05:29,480
A governance model that can't handle exceptions isn't robust.

1782
01:05:29,480 --> 01:05:32,040
It's brittle and brittle models always get bypassed

1783
01:05:32,040 --> 01:05:33,480
by the people trying to do their jobs.

1784
01:05:33,480 --> 01:05:35,160
The goal is to govern those exceptions

1785
01:05:35,160 --> 01:05:36,760
so they don't turn into permanent drift.

1786
01:05:36,760 --> 01:05:39,320
Every exception needs four things before it gets approved.

1787
01:05:39,320 --> 01:05:41,640
First, it needs an owner who is personally accountable for it.

1788
01:05:41,640 --> 01:05:43,400
Second, it needs a business justification

1789
01:05:43,400 --> 01:05:45,960
that explains why the standard path doesn't work.

1790
01:05:45,960 --> 01:05:48,200
Third, it needs a defined expiration date.

1791
01:05:48,200 --> 01:05:52,440
And fourth, it needs a review condition that surfaces the exception for recertification.

1792
01:05:52,440 --> 01:05:55,320
An exception without an expiration date isn't a managed exception.

1793
01:05:55,320 --> 01:05:57,960
It's just a policy violation with paperwork attached to it.

1794
01:05:57,960 --> 01:05:59,960
The paperwork doesn't make the environment safer.

1795
01:05:59,960 --> 01:06:02,040
It just makes the risk feel official.

1796
01:06:02,040 --> 01:06:05,480
PIM is the best mechanism for the most common type of exception

1797
01:06:05,480 --> 01:06:07,480
which is temporary elevated access.

1798
01:06:07,480 --> 01:06:11,800
Maybe a team needs subscription owner rights for 48 hours to finish a migration

1799
01:06:11,800 --> 01:06:14,760
or an incident response team needs to see production logs

1800
01:06:14,760 --> 01:06:16,200
outside their normal scope.

1801
01:06:16,200 --> 01:06:18,760
In every case, PIM managed activation is the right model.

1802
01:06:18,760 --> 01:06:21,480
It's time-bounded, it's MFA-gated, it's logged,

1803
01:06:21,480 --> 01:06:23,960
and it expires automatically when the window closes.

1804
01:06:23,960 --> 01:06:27,320
The access exists only for as long as it was justified.

1805
01:06:27,320 --> 01:06:31,560
When that window shuts, the account goes back to being eligible only.

1806
01:06:31,560 --> 01:06:34,120
Nobody has to remember to go back and revoke the permissions.

1807
01:06:34,120 --> 01:06:36,280
For the drift that doesn't require a human decision,

1808
01:06:36,280 --> 01:06:37,880
you use automated remediation.

1809
01:06:37,880 --> 01:06:40,840
These are the configuration gaps that policy is already built to fix.

1810
01:06:40,840 --> 01:06:42,200
Deploy?

1811
01:06:42,200 --> 01:06:44,760
If not exists, policies are your primary tool here.

1812
01:06:44,760 --> 01:06:48,280
If a resource is deployed and it's missing a required diagnostic setting,

1813
01:06:48,280 --> 01:06:51,640
the policy detects the gap and deploys the setting for you.

1814
01:06:51,640 --> 01:06:52,920
There is no ticket to open.

1815
01:06:52,920 --> 01:06:54,600
There is no remediation queue to manage.

1816
01:06:54,600 --> 01:06:57,160
There is no delay between finding the problem and fixing it.

1817
01:06:57,160 --> 01:07:00,040
The modify effect works the same way for properties you can change

1818
01:07:00,040 --> 01:07:01,560
after a resource is created.

1819
01:07:01,560 --> 01:07:03,880
It can add a required tag, adjust a network rule,

1820
01:07:03,880 --> 01:07:05,480
or update an encryption setting.

1821
01:07:05,480 --> 01:07:07,800
The policy engine doesn't just report that there's a gap.

1822
01:07:07,800 --> 01:07:09,000
It closes the gap.

1823
01:07:09,000 --> 01:07:11,000
Some misconfigurations are more complex.

1824
01:07:11,000 --> 01:07:13,560
They might require changes across multiple resources

1825
01:07:13,560 --> 01:07:15,560
that a single policy can't handle.

1826
01:07:15,560 --> 01:07:17,960
This is where the remediation pipeline pattern comes in.

1827
01:07:17,960 --> 01:07:19,720
When a policy non-compliance event fires,

1828
01:07:19,720 --> 01:07:21,320
an automated workflow picks it up.

1829
01:07:21,320 --> 01:07:25,320
It executes a standardized bicep or terraform module against the resource

1830
01:07:25,320 --> 01:07:27,160
because that module uses the same code

1831
01:07:27,160 --> 01:07:29,000
that governs your initial deployments.

1832
01:07:29,000 --> 01:07:31,320
The fixed state matches your baseline exactly.

1833
01:07:31,320 --> 01:07:32,600
The fix is version controlled.

1834
01:07:32,600 --> 01:07:33,880
The execution is locked.

1835
01:07:33,880 --> 01:07:36,120
The audit trail connects the non-compliance event

1836
01:07:36,120 --> 01:07:37,960
directly to the action that fixed it.

1837
01:07:37,960 --> 01:07:39,720
That is exactly what regulators want to see

1838
01:07:39,720 --> 01:07:41,560
when they ask how you handle drift.

1839
01:07:41,560 --> 01:07:43,800
Access reviews are the final cleanup mechanism.

1840
01:07:43,800 --> 01:07:45,640
They catch what automation can't reach.

1841
01:07:45,640 --> 01:07:47,640
Quartly review cycles bring role assignments

1842
01:07:47,640 --> 01:07:49,320
and entitlements to the surface.

1843
01:07:49,320 --> 01:07:51,480
They find the PIM activation that was extended once

1844
01:07:51,480 --> 01:07:52,440
and then forgotten.

1845
01:07:52,440 --> 01:07:54,360
They find the access package for a project

1846
01:07:54,360 --> 01:07:55,720
that ended four months ago.

1847
01:07:55,720 --> 01:07:58,200
They find the group membership for someone who changed teams

1848
01:07:58,200 --> 01:07:59,960
but kept their old permissions.

1849
01:07:59,960 --> 01:08:02,440
The reviewers make the decision to remove the access.

1850
01:08:02,440 --> 01:08:05,080
The process makes that decision visible and time-bounded.

1851
01:08:05,080 --> 01:08:06,760
It stops being dependent on someone

1852
01:08:06,760 --> 01:08:08,760
remembering to cleanup after themselves.

1853
01:08:08,760 --> 01:08:11,160
The governance life cycle isn't a project you finish.

1854
01:08:11,160 --> 01:08:13,400
You design the standards, you deploy the enforcement,

1855
01:08:13,400 --> 01:08:16,200
you monitor for the deviations, you remediate the drift,

1856
01:08:16,200 --> 01:08:17,720
you review what has accumulated,

1857
01:08:17,720 --> 01:08:20,280
and then you evolve the standards as the environment changes.

1858
01:08:20,280 --> 01:08:21,800
That cycle runs continuously.

1859
01:08:21,800 --> 01:08:23,880
Each time you go through it,

1860
01:08:23,880 --> 01:08:26,360
the environment gets closer to the state you defined.

1861
01:08:26,360 --> 01:08:28,040
The gap between what your governance says

1862
01:08:28,040 --> 01:08:30,040
and what actually exists gets a little smaller.

1863
01:08:30,040 --> 01:08:32,840
That shrinking gap is the definition of compliance as code,

1864
01:08:32,840 --> 01:08:34,200
working the way it was intended.

1865
01:08:34,200 --> 01:08:37,800
The 2026 compliance automation roadmap,

1866
01:08:37,800 --> 01:08:39,880
most organizations exist somewhere on a spectrum,

1867
01:08:39,880 --> 01:08:40,600
on one end.

1868
01:08:40,600 --> 01:08:42,520
You have policies written in word documents.

1869
01:08:42,520 --> 01:08:44,440
They're enforced by calendar reminders.

1870
01:08:44,440 --> 01:08:46,840
They're tested during annual audits that everyone dreads.

1871
01:08:46,840 --> 01:08:48,440
On the other end, you have policies in Git,

1872
01:08:48,440 --> 01:08:50,600
they're deployed through CI/CD pipelines.

1873
01:08:50,600 --> 01:08:52,360
They're validated continuously.

1874
01:08:52,360 --> 01:08:54,280
Audit evidence is generated automatically

1875
01:08:54,280 --> 01:08:55,960
and drift is detected within hours.

1876
01:08:55,960 --> 01:08:58,120
The distance between these two points isn't technical.

1877
01:08:58,120 --> 01:08:59,480
It's a maturity journey.

1878
01:08:59,480 --> 01:09:02,040
And knowing which phase your intels you exactly what to do next.

1879
01:09:02,040 --> 01:09:03,880
Phase one is visibility and inventory

1880
01:09:03,880 --> 01:09:06,120
because you can't govern what you can't see.

1881
01:09:06,120 --> 01:09:08,200
This phase is about getting an accurate picture

1882
01:09:08,200 --> 01:09:09,480
of your actual environment,

1883
01:09:09,480 --> 01:09:11,480
not the environment from the architecture diagram

1884
01:09:11,480 --> 01:09:12,840
you drew 18 months ago.

1885
01:09:12,840 --> 01:09:14,040
But what exists right now?

1886
01:09:14,040 --> 01:09:16,680
You need to know how many service principles are in your tenant.

1887
01:09:16,680 --> 01:09:19,000
You need to see how many have no documented owner.

1888
01:09:19,000 --> 01:09:20,280
You need to find the subscriptions

1889
01:09:20,280 --> 01:09:23,080
with direct user role assignments instead of group assignments.

1890
01:09:23,080 --> 01:09:25,880
How many key vaults still use legacy access policies?

1891
01:09:25,880 --> 01:09:28,280
What resources are publicly accessible that shouldn't be?

1892
01:09:28,280 --> 01:09:30,200
Audit mode policy assignments at scale

1893
01:09:30,200 --> 01:09:31,800
answer these questions fast.

1894
01:09:31,800 --> 01:09:33,320
You aren't enforcing anything yet.

1895
01:09:33,320 --> 01:09:34,440
You're just building the baseline

1896
01:09:34,440 --> 01:09:36,200
that every future decision depends on.

1897
01:09:36,200 --> 01:09:37,800
Organizations that skip this phase

1898
01:09:37,800 --> 01:09:40,040
and move straight to enforcement create incidents.

1899
01:09:40,040 --> 01:09:42,120
But the organizations that finish it properly

1900
01:09:42,120 --> 01:09:43,960
they know exactly where the enforcement will hurt

1901
01:09:43,960 --> 01:09:45,240
before it ever goes live.

1902
01:09:45,240 --> 01:09:47,640
Phase two is policy codification and enforcement.

1903
01:09:47,640 --> 01:09:50,360
This is where the architecture we've discussed actually gets built.

1904
01:09:50,360 --> 01:09:52,760
You take every security standard in your documentation

1905
01:09:52,760 --> 01:09:54,600
and translate it into a policy definition.

1906
01:09:54,600 --> 01:09:55,800
You move it into Git.

1907
01:09:55,800 --> 01:09:57,240
You deploy it through a pipeline.

1908
01:09:57,240 --> 01:10:00,040
Start every initiative in Audit mode to see what it catches.

1909
01:10:00,040 --> 01:10:01,400
Fix your IRC modules

1910
01:10:01,400 --> 01:10:03,560
so the compliant path is the default path.

1911
01:10:03,560 --> 01:10:06,440
Move to deny on the controls once the environment is ready.

1912
01:10:06,440 --> 01:10:08,120
This is when you build the golden paths.

1913
01:10:08,120 --> 01:10:10,280
You establish the PIM activation policies.

1914
01:10:10,280 --> 01:10:12,040
You migrate service principle authentication

1915
01:10:12,040 --> 01:10:14,840
to manage the identities for every workload that can handle it.

1916
01:10:14,840 --> 01:10:16,680
This phase takes longer than the first one.

1917
01:10:16,680 --> 01:10:19,160
It requires coordination across platform, security

1918
01:10:19,160 --> 01:10:20,600
and application teams.

1919
01:10:20,600 --> 01:10:23,400
The Earth's the digital case we talked about is a phase two story.

1920
01:10:23,400 --> 01:10:25,880
40 teams and 1,000 terraform workspaces

1921
01:10:25,880 --> 01:10:27,560
all brought under consistent guardrails

1922
01:10:27,560 --> 01:10:29,160
through deliberate platform design,

1923
01:10:29,160 --> 01:10:31,240
not through restriction, but through architecture.

1924
01:10:31,240 --> 01:10:34,600
Phase three is continuous monitoring and reporting.

1925
01:10:34,600 --> 01:10:37,240
This is where the governance architecture becomes self-sustaining.

1926
01:10:37,240 --> 01:10:39,240
Drift detection runs on a six hour cycle.

1927
01:10:39,240 --> 01:10:41,400
Correlation queries across intrasign in logs

1928
01:10:41,400 --> 01:10:44,840
and key vault diagnostics produce alerts on the patterns that matter.

1929
01:10:44,840 --> 01:10:46,520
Access reviews execute on schedule

1930
01:10:46,520 --> 01:10:49,800
and feed removal decisions back into the identity plane automatically.

1931
01:10:49,800 --> 01:10:53,560
Remediation pipelines close configuration gaps without human intervention.

1932
01:10:53,560 --> 01:10:55,560
Audit evidence is generated continuously.

1933
01:10:55,560 --> 01:10:57,720
Rather than being assembled under deadline pressure,

1934
01:10:57,720 --> 01:10:59,720
in this phase compliance isn't something you check.

1935
01:10:59,720 --> 01:11:00,920
It's something you operate,

1936
01:11:00,920 --> 01:11:04,360
but two shifts are arriving faster than most road maps account for.

1937
01:11:04,360 --> 01:11:09,960
First, purview's AI-powered regulatory templates reach general availability in August of 2026.

1938
01:11:09,960 --> 01:11:13,960
They change the relationship between regulatory, text and technical controls.

1939
01:11:13,960 --> 01:11:17,560
In the old model, a compliance team manually mapped a new regulation

1940
01:11:17,560 --> 01:11:20,280
to a set of policy definitions over several months.

1941
01:11:20,280 --> 01:11:23,240
In the new model, the system ingests the regulatory PDF

1942
01:11:23,240 --> 01:11:25,800
and produces actionable control mappings automatically.

1943
01:11:25,800 --> 01:11:27,720
The time between a new requirement appearing

1944
01:11:27,720 --> 01:11:29,560
and a technical control being deployed

1945
01:11:29,560 --> 01:11:31,480
compresses from months to days.

1946
01:11:31,480 --> 01:11:33,080
That isn't just a small improvement.

1947
01:11:33,080 --> 01:11:36,200
It restructures how compliance programs respond to change.

1948
01:11:36,200 --> 01:11:38,040
The second wave is co-pilot governance.

1949
01:11:38,040 --> 01:11:40,200
It's arriving whether you're ready for it or not.

1950
01:11:40,200 --> 01:11:44,760
AI agents operating inside your M365 environment are identity actors.

1951
01:11:44,760 --> 01:11:47,960
They authenticate via app registrations or managed identities.

1952
01:11:47,960 --> 01:11:50,520
They access data, they call APIs, they read from exchange,

1953
01:11:50,520 --> 01:11:52,040
they need the same governance treatment

1954
01:11:52,040 --> 01:11:53,960
as every other identity in your tenant.

1955
01:11:53,960 --> 01:11:56,680
That means scoped permissions, documented ownership,

1956
01:11:56,680 --> 01:11:59,000
access reviews and policy enforcement.

1957
01:11:59,000 --> 01:12:02,680
Organizations that govern AI agents with the same rigor they apply to humans

1958
01:12:02,680 --> 01:12:05,480
will have a defensible posture when regulators ask questions.

1959
01:12:05,480 --> 01:12:08,040
The ones treating AI agents as a separate category

1960
01:12:08,040 --> 01:12:11,000
are accumulating a debt that compounds with every agent they deploy

1961
01:12:11,000 --> 01:12:13,000
if you're making the case to leadership.

1962
01:12:13,000 --> 01:12:13,800
Remember this.

1963
01:12:13,800 --> 01:12:16,440
Compliance as code is not a security budget line.

1964
01:12:16,440 --> 01:12:18,360
It's a delivery velocity investment.

1965
01:12:18,360 --> 01:12:21,720
Governance that runs automatically doesn't slow developers down.

1966
01:12:21,720 --> 01:12:25,480
It removes the friction that stops them while they wait for an approval skew to move.

1967
01:12:25,480 --> 01:12:27,000
Audits stop being crises.

1968
01:12:27,000 --> 01:12:29,160
They become routine evidence collection.

1969
01:12:29,160 --> 01:12:31,400
The trade-off between moving fast and staying secure.

1970
01:12:31,400 --> 01:12:32,840
Simply stops being a trade-off.

1971
01:12:32,840 --> 01:12:36,040
Start with one management group, one initiative, one golden path,

1972
01:12:36,040 --> 01:12:37,800
prove the model in a small scope,

1973
01:12:37,800 --> 01:12:39,960
and then expand from demonstrated value.

1974
01:12:39,960 --> 01:12:41,800
Governance stops being a checkpoint.

1975
01:12:41,800 --> 01:12:43,720
It becomes the infrastructure itself.

1976
01:12:43,720 --> 01:12:45,800
And that shift changes everything downstream.

1977
01:12:45,800 --> 01:12:47,720
This week I want you to open one subscription,

1978
01:12:47,720 --> 01:12:49,640
count your direct user, our back assignments,

1979
01:12:49,640 --> 01:12:51,000
against your group assignments.

1980
01:12:51,000 --> 01:12:53,880
That ratio tells you exactly how much drift you're already carrying.

1981
01:12:53,880 --> 01:12:55,960
Before you've changed a single policy definition,

1982
01:12:55,960 --> 01:12:58,680
if this changed how you think about compliance architecture,

1983
01:12:58,680 --> 01:13:03,240
leave a review. It helps more people in the Microsoft ecosystem find this conversation.

1984
01:13:03,240 --> 01:13:04,840
Connect with me, Mirko Peters.

1985
01:13:04,840 --> 01:13:07,160
On LinkedIn, share what you found in that R-Back audit.

1986
01:13:07,160 --> 01:13:08,680
It shapes what we cover next.

1987
01:13:08,680 --> 01:13:12,520
In the next episode, we're looking at AI agents in your M365 environment.

1988
01:13:12,520 --> 01:13:16,120
They're becoming the new governance surface most organizations haven't planned for yet.

1989
01:13:16,120 --> 01:13:18,120
We're going deep on the identity layer.