Aventure Cloud Blog — 6 November 2026
Security protects things. Governance controls things. That is the simplest way to tell them apart — and the reason they are so often confused.
Security stops the wrong person getting in: who can sign in, what is encrypted, what is being attacked. Governance stops the wrong thing being built: what is allowed, what is compliant, what is organised, and what it costs.
Most Azure services sit on the line between the two. Entra ID is security — authentication. RBAC is governance — authorisation, who is allowed to do what — and security. Azure Policy is pure governance. Defender is pure security.
Keep this rule in mind as you read the rest:
Governance stops the wrong thing being built. Security stops the wrong person getting in.
1. Identity and Access — Security + Governance
| Service | What it does |
|---|---|
| Microsoft Entra ID | Identity — users, groups, apps, devices, sign-in, MFA |
| RBAC (Role-Based Access Control) | Authorisation — who can do what, on which scope (subscription / resource group / resource) |
| Privileged Identity Management (PIM) | Just-in-time admin — eligible roles, activation with approval + MFA, time-limited, audited |
| Conditional Access | Policies — only allow sign-in from a compliant device, in this country, with MFA |
| Multi-Factor Authentication (MFA) | Second factor for sign-in |
| Managed Identity | Passwordless identity for Azure services — system-assigned (one resource) or user-assigned (shared across many) |
| Service Principal / App Registration | Identity for applications outside Azure — client ID + client secret / certificate |
| Entra ID Protection | Risk detection — leaked credentials, impossible travel, risky sign-ins |
| Entra ID Governance | Access reviews, entitlement management, lifecycle workflows |
| Entra Permissions Management (CIEM) | Finds over-privileged identities across Azure, AWS, GCP |
Who uses what identity?
| Identity | For whom / what? | Managed by |
|---|---|---|
| User (member) | Employee | You / HR |
| User (guest) | External partner / vendor (B2B) | You, via B2B invite |
| Group | Set of users | You |
| Device | Laptop / phone / VM | Entra ID + Intune |
| Service Principal | An application (yours or a vendor’s) | You — you manage the secret |
| Managed Identity | An Azure resource | Azure — no secret to manage |
| Workload Identity Federation | An external workload (GitHub Actions, Kubernetes) | Trust, no secret stored |
Rule: People get in through a user in a group. Apps get in through a Managed Identity. Never give an app a human user’s account, and never give a human a Managed Identity.
Service Principal — step by step
A Service Principal is a username + password for an application, not a person. Use it when an app runs outside Azure — a script, GitHub Actions, an on-prem app. Inside Azure, use Managed Identity instead.
- Step 1 — Register the app: Entra ID → App registrations → New registration (e.g. my-storage-reader-app). Azure gives it a Client ID — the app’s username.
- Step 2 — Azure creates the Service Principal automatically when you register the app. App Registration = the app’s birth certificate; Service Principal = the account that can sign in.
- Step 3 — Create a secret: Certificates & secrets → New client secret, with an expiry. Copy the value once — you cannot see it again. Store it in Key Vault, never in code.
- Step 4 — Give it permission: target resource → Access control (IAM) → Add role assignment, least-privilege role (e.g. Storage Blob Data Reader), assign to the Service Principal by app name.
- Step 5 — Use it in code: ClientSecretCredential with tenant ID + client ID + client secret (from Key Vault).
- Step 6 — Rotate before expiry: create a new secret, update Key Vault / pipeline, delete the old one. If you forget, the app stops working on the expiry date.
The same idea, in other clouds
The pattern is the same on AWS and GCP, only the names change. On AWS, IAM users and roles, IAM Identity Center, and Organizations with Service Control Policies (SCPs) play the Entra ID, RBAC, and Management Group roles. On GCP, Cloud IAM, Workforce Identity Federation, and Organization Policy do the same job. In a multi-cloud setup, keep one rule everywhere: humans in groups with MFA, workloads with a cloud-managed identity, and no long-lived secret where a federated identity will do.
2. Network Security
| Service | What it does |
|---|---|
| Network Security Groups (NSG) | Firewall rules on subnets / NICs — allow/deny by port, IP, protocol |
| Azure Firewall | Managed cloud firewall — L3/L4 + L7, threat intel, DNS proxy |
| Web Application Firewall (WAF) | Protects web apps from SQL injection, XSS, OWASP Top 10 — on Application Gateway / Front Door / CDN |
| DDoS Protection | Network-level DDoS mitigation |
| Private Link / Private Endpoint | Private access to PaaS services — no public internet |
| Private DNS Zones | Private name resolution for Private Endpoints |
| Bastion | Secure RDP/SSH to VMs without a public IP |
| VPN Gateway / ExpressRoute | Private connectivity from on-premises to Azure |
| Network Watcher | Flow logs, NSG diagnostics, connectivity checks |
| Azure DNS Private Resolver | Conditional forwarding between on-prem DNS and Azure Private DNS |
In a landing zone, DNS is a hub service, not a per-workload afterthought. The most common Private Endpoint failure is a missing Private DNS record or a missing VNet link — the service is reachable, but the name does not resolve to the private IP.
3. Data Protection
| Service | What it does |
|---|---|
| Key Vault | Secrets, keys, certificates — RBAC, soft-delete, purge protection |
| Managed HSM | Dedicated hardware security module for keys |
| Encryption | Storage Service Encryption, disk encryption, TDE for SQL, TLS in transit |
| Customer-Managed Keys (CMK) | You own the encryption key in Key Vault, not Microsoft |
| Microsoft Purview | Data governance — classification, labelling, data lineage, DLP |
| Information Protection / Sensitivity Labels | Label and encrypt documents and emails |
| Data Loss Prevention (DLP) | Block sharing of sensitive data (e.g. credit card numbers) |
Encryption is not the same as private access. A storage account can be encrypted and still be publicly reachable. You need all three: encryption, a Private Endpoint, and public access denied.
4. Threat Protection and Monitoring
| Service | What it does |
|---|---|
| Microsoft Defender for Cloud | CSPM — posture management, Secure Score, recommendations, compliance dashboards |
| Microsoft Defender XDR | Extended detection and response across identity, endpoint, email, cloud apps |
| Microsoft Defender for Identity | Detects attacks on Entra ID / AD (lateral movement, pass-the-hash) |
| Microsoft Defender for Endpoint | EDR on servers and workstations |
| Microsoft Defender for Cloud Apps | CASB — shadow IT, SaaS app risk |
| Microsoft Sentinel | SIEM + SOAR — collect logs, detect threats, automate response with playbooks |
| Azure Monitor / Log Analytics | Logs, metrics, alerts — the data layer under Defender and Sentinel |
5. Governance — Organisation and Control
| Service | What it does |
|---|---|
| Management Groups | Hierarchy above subscriptions — apply policy and RBAC at scale |
| Azure Policy | Guardrails — only allow these regions, require a tag, deny public Storage, require private endpoints — audit, deny, deploy-if-not-exists |
| Policy Initiatives | Bundles of policies (e.g. CIS or NIST initiative) |
| Resource Locks | Prevent accidental delete / modification (CanNotDelete, ReadOnly) |
| Tags | Organisation — cost centre, environment, owner, on every resource |
| Resource Graph | Query all resources across subscriptions at scale |
| Cost Management + Billing | Budgets, cost analysis, alerts — governance of spend |
| Landing Zones / Cloud Adoption Framework (CAF) | The governance design — platform vs workload subscriptions, management groups, policy, networking |
| Azure Arc | Governance of non-Azure resources (on-prem servers, other clouds) under the same Policy / RBAC |
The Cloud Adoption Framework landing-zone model is simple at its core: a platform landing zone holds the shared services — identity, networking, management — and workload landing zones hold the applications, inheriting policy from above. AI resources belong in workload subscriptions, never in platform subscriptions.
6. Compliance
| Service / concept | What it does |
|---|---|
| Defender for Cloud — Regulatory Compliance | Maps posture to CIS, NIST, ISO 27001, PCI DSS, HIPAA |
| Microsoft Purview Compliance Manager | Compliance score, assessments, evidence |
| Audit logs | Entra sign-in logs, Activity Log, diagnostic settings — who did what, when |
| Azure Attestation | Prove a platform / workload is running trusted code |
Compliance is evidence, not a feeling. Every claim should be traceable to a real record — a Policy compliance result, a Defender recommendation, a sign-in log — with a link and a timestamp.
7. Using Agents to Automate and Audit Security and Governance
Agents are very useful in this area, with one rule: agents can audit and prepare remediation — a human approves the change.
What agents can automate
| Use case | What the agent does | Human decision |
|---|---|---|
| Continuous compliance audit | Reads Azure Policy, Defender for Cloud Secure Score, and Resource Graph; finds resources without tags, Storage with public access, Key Vaults without purge protection, NSGs with open port 22/3389, standing Owner access; produces a prioritised report with evidence | Approve the fix list, or accept the risk |
| Identity audit | Finds over-privileged users and Service Principals, standing admin roles that should be PIM-eligible, secrets expiring in 30 days, unused permissions, guest users with no use in 90 days; drafts access-review recommendations | Approve or revoke access |
| Incident triage (Sentinel) | Pulls related logs, identity, resource, and recent changes for a Sentinel alert; writes a first triage summary — what happened, blast radius, known pattern — and suggests next steps | Approve containment; agent never isolates a VM or disables an account alone |
| Remediation drafting | Prepares the fix as code — Terraform/Bicep patch, Policy remediation task, or Azure CLI command (e.g. enable diagnostic settings, rotate a Service Principal secret) | Approve via pull request / PIM activation; agent never applies it silently |
| Cost and governance cleanup | Finds unused resources, oversized VMs, unattached disks, old snapshots; drafts a cleanup list with saving per item | Approve before any deletion — deletion is never automated without a human |
| Key Vault and secret audit | Tracks secret/key/certificate expiry, rotation, and access; flags secrets about to expire | Approve rotation plan |
| Network exposure audit | Finds public endpoints, missing private endpoints, open NSGs, and drift from the landing-zone network design | Approve remediation |
How to build it — in Foundry terms
Defender / Policy / Sentinel / Resource Graph / Entra logs → AI Search index (grounding — the agent only answers from real data) → Foundry agent (GPT-4o) with tools: Resource Graph query tool; Policy compliance tool; Key Vault / RBAC read tool (read-only); Draft remediation tool (prepares, does not apply) → Human reviewer approves → Remediation runs via pipeline, with full audit log. Tools are read-only by default. The write tool is separate, and it only prepares the change.
What agents must NOT do in this area
- Never auto-revoke access or delete a resource on their own — a wrong revocation can take down production.
- Never rotate a secret and not tell anyone — the app using it will break.
- Never invent a compliance result — every finding must cite the actual Policy / Defender record it came from, with a link and a timestamp.
- Never act on a log it cannot verify — if the evidence is missing, it says “could not verify”, not “compliant”.
The pattern to remember: build a Foundry agent grounded in Defender for Cloud, Azure Policy, and Resource Graph, with read-only tools to audit RBAC, Key Vault expiry, and non-compliant resources, and a separate draft-only tool to prepare remediation as code. The agent audits and prepares — a human approves the change, and every action is logged in the Activity Log and Sentinel. That keeps the automation fast without giving an agent standing write access to production.
The takeaway
Entra ID is identity security, RBAC is the authorisation layer that sits on top of it — so both are security and governance. Around them: PIM for just-in-time admin, Conditional Access for sign-in policy, Azure Policy and Management Groups for guardrails at scale, Key Vault for secrets, Private Link and Firewall / NSG / WAF for network, Defender for Cloud for posture, and Sentinel as the SIEM.
Governance is what stops the wrong thing being built; security is what stops the wrong person getting in. Get both right, and the cloud stays fast and safe.
Want to learn to build and govern cloud systems like this? Email info@aventurecloud.net. For training enquiries, email info@aventurecloud.net. For careers, email hr@aventurecloud.net.
No responses yet