Microsoft Azure
Also known as: Azure
Following adds this technology to your private workspace so related learning is easier to organise and revisit.
What is Microsoft Azure?
Microsoft Azure is a global cloud platform providing compute, networking, storage, data, identity, security and managed application services. This profile connects the concept to KBY's practical engineering guidance.
Resources are organised into tenants, subscriptions, resource groups and regions and controlled through Azure Resource Manager. Microsoft Entra identity, role-based access, policy and service-specific network controls define much of the operational boundary.
Build and operate applications and infrastructure using Microsoft-managed cloud services.
- Enterprise cloud infrastructure
- Hybrid cloud architectures
- PaaS for application development
Explore related technologies
Sub-technologies
21+ resources for Microsoft Azure
Browse by purpose, from definitions and learning through operations, diagnostics and controlled recovery.
Learn and operate with Microsoft Azure
Ordered as a reader progression -- from core definitions through to operational reference -- using only the content already connected in the technology registry.
Systems Engineering(1)
Learn the architecture, concepts and engineering context.
Graduate Learning(2)
Build practical knowledge and hands-on skills.
Config Traps(12+)
Recognise and avoid known failure modes.
- Leftover Client Secrets Let DefaultAzureCredential Bypass Azure Workload IdentityA leftover client secret in a pod's environment lets the Azure Identity SDK's default credential chain silently bypass Azure Workload Identity federation, keeping a long-lived secret active without any visible error. Open
- Conditional Access in Report-Only Mode Never Enforces MFAA correctly built Conditional Access policy that is still set to Report-only will log matching sign-ins but never enforce MFA or blocking, giving teams false confidence that privileged accounts are protected. Open
- Missing Purge Protection Undermines Key Vault Soft-Delete RecoverySoft-delete on Azure Key Vault looks like a full safety net, but purge protection is a separate control that is not guaranteed to be on. Without it, anyone with purge rights can destroy vault contents permanently and immediately. Open
- Default Outbound Allow in Azure NSGs Enables Data ExfiltrationA hardened-looking Azure NSG can still leave a silent outbound exfiltration path open, because the platform's default outbound allow rule survives unless explicitly overridden. Open
- Azure Storage Security Misconfiguration Lacks Verified EvidenceA config-trap draft for Azure Storage Security that is withheld from full technical specifics pending verified, reproducible evidence, and flagged for human review. Open
- Rotation Service Principals Inherit Key Vault PurgeA secret-rotation identity holding purge rights can erase every version of a Key Vault secret outright, skipping the 90-day soft-delete window entirely. Once triggered by a scripting error or a leaked credential, no vault backup, RBAC lockout, or incident response runbook restores what was purged. Open
- Azure SAS Tokens That Outlive Key RotationAn Azure Storage account SAS minted with account-wide scope keeps working after a scheduled key rotation, because rotation runbooks routinely regenerate only key1 while the token was signed with key2, and no stored access policy exists to revoke it independently. RBAC and firewall rules never see the request, since SAS bypasses Azure AD authorisation entirely. Open
- App Service UAMI at Management Group Scope: Token TheftA single compromised App Service process can request an OAuth token from the local identity endpoint and use it far outside the app's own subscription. When the attached identity carries a Management Group role assignment, that token becomes a pivot point across every subscription beneath it, and network egress rules never see the request leave the box. Open
- Subscription-Scoped Federated Credentials Widen UAMI TrustA federated credential on a user-assigned managed identity issues tokens purely on issuer, subject and audience claims, then Azure RBAC assigns that identity Contributor at subscription scope. Any workload capable of matching the subject claim inherits control over every resource group underneath, and Conditional Access never sees the exchange. Open
- Azure App Service's Two Basic Auth Policies, Not OneDisabling Basic Auth in the Azure Portal only touches the SCM publishing policy, not the separate FTP policy resource. Leaked publish profile credentials still authenticate over FTPS, and Always On keeps the resulting worker process running indefinitely instead of idling out, so normal recycling never interrupts an uploaded webshell. Open
- Key Vault Access Policy Templates Bundle Purge RightsA CI/CD service principal holding the Azure Key Vault access policy preset for certificate, key and secret management inherits the purge permission alongside routine lifecycle rights. If that principal's credential leaks, keys, secrets and certificates can be permanently destroyed within the recovery window, and standard soft-delete controls provide no backstop. Open
- Storage Account Keys Still Bypass Azure RBACA storage account with fine-grained Azure RBAC still grants full data-plane access to anyone holding its account key, because Azure Storage's shared-key authentication path never consults Azure AD. Conditional Access, MFA and RBAC scoping are silently skipped whenever a leaked key or classic SAS token reaches blob, queue or table endpoints. Open
Incident Runbooks(6)
Stabilise, recover and validate during incidents.
- Azure Network Security Group default rule allowing AllowVnetInBound combined with flat non-segmented VNet peering across production and devThe built-in AllowVnetInBound rule (priority 65000) matches the VirtualNetwork service tag, which silently expands to include every directly peered address space. When production and development VNets are peered without hub-spoke segmentation, a compromised dev host gains unrestricted inbound reachability to production subnets with no NSG intervention required. Open
- Azure Storage Account default shared key access enabled instead of enforcing Azure AD RBAC-only authenticationStorage accounts provisioned via ARM, Bicep, or Terraform without an explicit allowSharedKeyAccess value default to true, leaving account-key authentication live alongside Azure AD RBAC. Any process holding the key or a derived SAS token reads and writes data completely outside Conditional Access, PIM, and role assignment scope, regardless of how tightly RBAC is configured. Open
- Azure App Service default 'Always On' combined with anonymous FTP/FTPS deployment credentials left activeAzure App Service instances provisioned with ftpsState left at AllAllowed and unrotated publish credentials permit direct FTP/FTPS writes into /site/wwwroot. Because Always On keeps the worker process permanently warm, any webshell dropped via FTP persists indefinitely without a cold-start eviction, giving attackers a durable, low-noise foothold that survives normal idle-timeout recycling. Open
- Azure Network Security Group default 'AllowVnetInBound' rule combined with flat VNet peering exposing lateral movementFull-mesh VNet peering without a hub firewall means every NSG's default AllowVnetInBound rule resolves the VirtualNetwork service tag to the combined address space of all directly peered VNets. A single compromised host in any spoke gains unrestricted L3/L4 reachability into every other peered tier unless explicit deny rules override the 65000-priority default. Open
- DNS CNAME records pointing to deprovisioned Azure/AWS resources creating subdomain takeover vulnerabilitiesA CNAME left in Azure DNS or Route 53 after an App Service, Storage account, S3 bucket, or Elastic Beanstalk environment is deleted still resolves to a provider-managed namespace. Because Azure App Service names and S3 bucket names are globally reusable once released, any external party can register the identical name and immediately serve content under your legitimate subdomain. Open
- Azure Key Vault access policies configured with 'purge' permission without soft-delete or purge protection enabledA vault-level misconfiguration where enablePurgeProtection remains false while an access policy still grants the 'purge' verb on keys, secrets, or certificates. Any principal holding that permission can permanently destroy vault objects the instant they are deleted, bypassing the 90-day soft-delete recovery window entirely and with no audit-time warning. Open