Access Control & Policy Enforcement

Module 7b · Access Control

Security Champions · Module 7b

From least privilege to policy-as-code. Part 2 of 2.

01 / 24 · Cover

Recap · Part 1

PART 1 RECAP

Part 1: why configurations go wrong. Part 2: how to control access and enforce policies.

Recap

Act 4 · Cloud identity

The trust boundary moved

In traditional environments, identity was simple: a trusted domain, a directory server, users and applications all inside the firewall. You knew who was who because you controlled the network.

Cloud changed everything. Applications run outside the domain. Users connect from anywhere. Mobile devices have no domain membership. Multi-tenant applications serve users from different organizations. The old trust model — "if you're on the network, you're trusted" — broke.

Three questions replaced it: How does the application trust data sent by the identity store? How does the identity store know it's safe to send user data to the application? How do you support organizations with no identity infrastructure at all?

The answer to all three: token-based identity protocols.

03 / 24

Act 4 · Token auth

How token auth works

Security Token — a signed collection of claims about a user. The signature proves the token wasn't tampered with. Claims — name/value pairs describing the user: email, display name, group memberships, roles. Security Token Server (STS) — a service that verifies user identity and issues tokens. OAuth2 — the protocol for requesting, issuing, and using tokens to access protected resources.

The flow in practice: your application redirects the user to the identity provider (Azure AD, Okta, etc). The user authenticates there — your application never sees the password. The identity provider returns a token. Your application uses that token to access resources.

Key insight: The application has no access to user credentials. It doesn't know how the user authenticated. It only knows the claims in the token.

OIDC is an add-on to OAuth2. OAuth2 gives you an access token (for accessing resources). OIDC adds an identity token (for knowing who the user is). Most modern applications need both.

04 / 24

Time to think · Auth flow

TOKEN-BASED IDENTITY

The application never sees credentials. It only sees tokens. The identity provider is the trust anchor.

Auth flow

Act 5 · Least privilege

Authentication vs authorization

Authentication answers "who are you?" Authorization answers "what can you do?" They're separate concerns, but most organizations conflate them — or handle authorization inconsistently across services.

Two approaches compete:

IDP-driven authorization — roles, permissions, or claims are embedded in the JWT token itself. When the user authenticates, they receive a token that already says "this user can read invoices, write orders, and admin the dashboard." Fast. No additional lookup needed. But the token can become bloated, and permission changes require a new token.

Group-to-role binding — the token contains only group memberships. Each service has its own role configuration: "group:engineers → role:developer → permissions:read,write." More flexible. Permission changes don't require new tokens. But more configuration per service.

There's no golden bullet. Both work. The choice depends on your architecture.

06 / 24

Act 5 · Choosing the model

Choosing the model

Use group-to-role binding when: your service doesn't support JWT claims natively — many tools only support internal role assignment. Your permission set changes frequently — managing permissions at the service level is faster. Your JWT token would become too large — when a user has many roles across many services, the token bloats.

Use IDP-driven claims when: your architecture is simple — few services, stable permissions, clear role model. Claims in the token mean zero additional lookups. You need consistent authorization across many services — one source of truth, one place to audit.

In practice, many teams use JWT tokens for authentication only and fetch current permissions from a database or cache at request time. This avoids stale claims, supports frequent permission changes, and keeps the token small. The trade-off: an additional lookup per request.

07 / 24

★ Best practice

★Best Practice

Start everyone with read-only access. Let the role matrix build itself.

Day one: Every developer, every DevOps engineer gets read-only access to the cloud account. Nothing more.

When someone needs more: They create a Jira ticket. "I need write access to the S3 bucket for deploying static assets." The ticket is reviewed, approved, and the permission is granted.

Why this works: 95% of what engineers need day-to-day is read-only — checking logs, investigating issues, reading configurations. Every permission above read-only is tracked and justified. Over time, the tickets naturally form a role matrix — you can see which permissions each role actually needs.

The alternative — starting from no access at all — sounds more secure but creates chaos. You'll be overwhelmed with access requests and become a bottleneck. Read-only is the practical sweet spot.

If you have time to prepare, build a role matrix first (resources × roles, start from no-access, justify each cell). If you're under pressure — read-only access, permissions via tickets. Both arrive at the same destination.

08 / 24 · Best Practice

Act 5 · Duties

Different hands on different levers

Separation of duties means no single person controls an entire process end-to-end. The person who writes the code doesn't approve the merge request. The person who assigns permissions doesn't have those permissions themselves. The person who deploys to production doesn't have access to modify the deployment pipeline.

This isn't about distrust. It's about creating a system where mistakes — and malicious actions — require collusion instead of a single point of failure.

Merge requests require approval from someone other than the author. Production deployments require a different person's sign-off. IAM permission changes go through a request → review → approve workflow. No single person can both create a service account AND assign it permissions. Audit logs track who did what — if someone bypasses the process, it's visible.

09 / 24

Act 5 · Conditional access

Beyond who — where, when, how

Traditional access control asks one question: "Does this identity have the required permission?" Conditional access adds context: where are they? When are they accessing? What device are they using?

Even if a user has the correct permissions, a login attempt from an unusual country at 3am from an unmanaged device should trigger additional verification — or be blocked entirely.

Azure's Conditional Access (in Microsoft Entra) evaluates: User attributes — role, group membership, risk score. Device attributes — managed vs unmanaged, OS version, compliance status. Location — IP address, country, named locations. Time — outside business hours, unusual patterns. Application — which resource is being accessed.

Conditional access is the difference between "you have the right key" and "you have the right key AND you're using it from the expected door at the expected time."

10 / 24

Act 5 · Zero Trust

Never trust, always verify

Zero Trust is the architectural model that ties everything together. The core principle: no implicit trust based on network location, device, or previous authentication.

Every access request is verified independently. Every session is validated continuously. Every permission is scoped to the minimum required.

This isn't just "don't use VPNs." It's a set of practices: Verify identity explicitly — authenticate every request, not just the first one. Use least-privilege access — just-in-time permissions, just-enough access. Assume breach — design as if the attacker is already inside the network (which, statistically, they probably are).

If this sounds familiar — it's the same "Assume Breach" paradigm from Module 5. Zero Trust is Assume Breach applied to access control.

11 / 24

Knowledge check · access control

Knowledge check

Your team is starting a new project. The DevOps lead requests contributor access to the AWS account for the whole team of 8 — "so we can move fast without access bottlenecks." What's the best response?

D. If you have time to prepare, build the role matrix first (option C) — it's the more structured approach. If you're under pressure and need to start immediately, read-only with ticket-based upgrades (option B) gets you to the same destination with less upfront work. Never grant contributor to everyone — you'll spend months cleaning up the permission sprawl.

12 / 24 · Quiz

Time to think · Permissions

PERMISSION ACCUMULATION

Permissions accumulate like debt. Reviews are the only way to pay it down.

Pause and reflect

Act 6 · Policy enforcement

Scanning the code

Infrastructure-as-code brought configuration under version control — a major improvement. But IaC is still code, and code has bugs.

The scanning tools: Checkov, Terrascan, TFSec, Trivy — all check Terraform (and other IaC) files for misconfigurations. Missing encryption flags. Overly permissive security groups. Public access on storage buckets. They run in the CI/CD pipeline and block merge requests that violate policies.

But here's what they miss: not all default checks cover all potential issues. If you have specific requirements, you need custom policies. Open Policy Agent (OPA) fills this gap — a declarative policy engine where you specify what to check in a policy language (Rego), and OPA evaluates your files against those policies.

Syntax checking/linting (fast, catches typos), unit testing (mock the runtime, check logic consistency), integration/acceptance testing (model expected state, run changes against real or simulated environment, verify outcome). Most teams stop at linting. The teams that get configuration right test their infrastructure code like they test application code.

14 / 24

★ Best practice

★Best Practice

Scan the code AND enforce in the cloud

IaC scanners check your Terraform files. But they don't check what someone created via the AWS console or Azure portal at 2am.

Cloud policies — AWS Service Control Policies (SCP) and Azure Policies — are the second layer. They evaluate resource creation in real-time, regardless of how the resource is created: Terraform, CLI, console, API call.

Layer 1: Code — Checkov/Terrascan/OPA in the pipeline → catches misconfigs before they reach the cloud. Layer 2: Cloud — SCP/Azure Policies → catches everything else, including manual changes.

Neither layer alone is sufficient. Together, they cover both the planned path (IaC) and the unplanned path (manual intervention).

Align your IaC scanner rules with your cloud policies. If Checkov allows something that SCP blocks, you'll discover the mismatch at deploy time — the most expensive place to learn.

15 / 24 · Best Practice

Act 6 · Frameworks

Don't write policies from scratch

You don't need to invent your baseline. Established frameworks provide comprehensive, battle-tested policy sets.

CIS Benchmarks — detailed configuration guides for AWS, Azure, GCP, Kubernetes, databases, operating systems. Community-driven, regularly updated. The most widely used.

NIST Framework — broader governance framework. Useful for mapping security controls to business objectives. Often required by compliance.

DoD STIG Templates — military-grade hardening guides. Available as Puppet/Ansible modules. Extremely detailed, sometimes more restrictive than necessary for commercial environments.

dev-sec.io — open-source hardening framework from Deutsche Telekom. Provides Ansible, Chef, and Puppet modules for Linux, SSH, MySQL, PostgreSQL, and more.

Having at least one of these as a baseline — even just notifications, not blocking — is better than having nothing. It gives you a reference point for measuring drift.

16 / 24

Act 6 · Metrics

Measuring security posture

You can't improve what you don't measure. Four metrics give you a clear picture of your configuration security posture:

Blocked secrets count — how many hardcoded secrets did the pipeline catch this month? Trend up = either more developers or more carelessness. Trend down = the culture is working.

Blocked merge requests — how many MRs failed security checks? High numbers early = the team is learning. Persistent high numbers = the policies might be too strict, or the team isn't adapting.

Role count changes — scan your IAM roles regularly. Last scan: 42 roles. This scan: 45 roles. Why +3? Each new role should be justified.

Privileged port exceptions — how many security group rules allow non-standard access? Each one should be tracked and reviewed.

Even something as simple as role count can serve as a reference metric. Plus two roles since last month — why? That question alone catches configuration drift.

Your role as a Champion: ensure your team has a written baseline, track every drift from it as a defect in Jira, and report these four metrics to your security team quarterly. You don't set the policies — you make sure they're being followed and the gaps are visible.

17 / 24

Knowledge check · policy

Knowledge check

Your team uses Terraform with Checkov in the CI/CD pipeline. All Terraform code is reviewed and passes security checks. A developer creates an S3 bucket with public access directly via the AWS console for a quick demo. Does Checkov catch it?

B. IaC scanners check code, not cloud reality. The console-created bucket exists only in AWS, not in any Terraform file. You need AWS Service Control Policies (SCP) or AWS Config rules to catch resources created outside of IaC. This is why two-layer enforcement — code scanning + cloud policies — is essential. Tools like Wiz, Prisma Cloud, and AWS Security Hub (CSPM — Cloud Security Posture Management) automate continuous cloud state scanning across both layers.

18 / 24 · Quiz

Knowledge check · authorization

Knowledge check

Your application uses Azure AD for authentication. Users receive JWT tokens containing group memberships. Each backend service maps groups to internal roles. A developer says: "We should move all permissions into the JWT claims instead — it's faster, one source of truth." What's the risk?

D. Moving all permissions into JWT claims creates two problems. First, token bloat: if users have different permissions across many services, the token grows significantly (some services have size limits). Second, staleness: claims are set at authentication time. If permissions change, the user keeps the old claims until they get a new token. Group-to-role binding avoids both issues — groups are stable, permissions are managed per service.

19 / 24 · Quiz

Time to think · Two layers

TWO-LAYER ENFORCEMENT

Scan the code. Enforce in the cloud. Neither alone is enough.

Two-layer visualization

Practice · Assignment

Your assignment

Audit your project's access control and configuration posture:

1. Permission inventory — list who has what access to your cloud accounts. Can you justify every permission above read-only?

2. Baseline check — do you have a written configuration baseline? If yes, when was it last compared to the actual state?

3. Pipeline scanning — are Checkov/Terrascan/similar tools in your CI/CD pipeline? Have you added custom policies?

4. Cloud policies — do you have AWS SCP or Azure Policies active? Do they align with your IaC scanner rules?

5. Metrics — can you report on blocked secrets, role count changes, or security group exceptions?

Install Checkov in your pipeline if it's not there — one afternoon. Enable CIS Benchmark notifications in your cloud account — one click. Export your IAM roles and count them — baseline for future comparison. Review one team member's permissions — start the habit.

21 / 24 · Assignment

Part 2 · Summary

What you covered

01

Authentication is solved (tokens, SSO, OIDC). Authorization is where the complexity lives — IDP-driven claims vs group-to-role binding, choose per context.

02

Start with read-only. Add permissions via tickets. 95% of daily work is read-only. The role matrix builds itself.

03

Conditional access adds "where, when, how" to "who" — the same permissions should behave differently at 3am from an unknown IP.

04

IaC scanners catch code misconfigs. Cloud policies catch manual changes. You need both layers.

05

Measure it: blocked secrets, blocked MRs, role count changes. If you're not counting, you're not improving.

22 / 24 · Summary

Module 7b · Results

Your results

Part 2 complete

—

Correct

—

XP earned

—

Best streak

23 / 24 · Score

Next · Module 8

You now understand how to control configurations, manage access, and enforce policies automatically. Next: the topic continues with the next lecture in the series.

24 / 24 · Next