General IAM Principles

Overview

Identity and access management is the cloud's primary attack surface. The cloud control plane is reached over the public internet through an API that authenticates the caller and authorises the action; whoever holds the credential holds the resource. Network perimeters, host hardening, and data encryption are all secondary defences when an attacker can sign a legitimate API call. The ENISA Threat Landscape 2025 names identity-related compromise — phishing, credential stuffing, infostealer-sourced session theft, OAuth consent abuse — as the dominant initial-access vector against cloud tenants, and successive Verizon Data Breach Investigations Reports continue to attribute the largest single share of breaches to stolen or misused credentials.

This page sets the provider-neutral principles a reader internalises before opening any provider's IAM page. Six principles cover the material — least privilege, separation of duties, multi-factor authentication, identity federation, secrets management, and privileged access — each named once here and then mapped onto provider primitives on the four provider IAM pages: AWS IAM Hardening, Azure IAM Hardening, GCP IAM Hardening, and OCI IAM Hardening. The same principles connect to the broader threat model: see general/threat-model.html for Chain A (credential theft → lateral movement → exfiltration), and to shared-responsibility.html for the customer-owned identity layer that this page elaborates.

A note on scope. This page covers principles, not controls. Concrete configurations — Service Control Policy syntax, Conditional Access expressions, IAM Conditions CEL, OCI policy statements — live on the provider pages. The cross-provider mentions here are one sentence each; the depth lives in Phase 5 provider IAM pages and the controls they enumerate.

Principle 1: Least privilege

Least privilege means a principal — human user, workload identity, automation service account — holds only the permissions required to perform its assigned task, no more, and only for the duration the task requires. The principle is older than the cloud; NIST SP 800-53 rev5 control AC-6 has codified it for decades. What is new in the cloud is the granularity. A modern provider IAM model exposes thousands of distinct actions across hundreds of services, and the default ergonomic path for an engineer in a hurry — attach the broadest managed policy that makes the deploy succeed — produces the over-permissive identity that turns a credential leak into a tenant-wide compromise.

The four major cloud providers expose closely related least-privilege primitives, but the surface shape differs in ways that matter for design. AWS implements least privilege through identity-based policies attached to users, groups, and roles, combined with resource-based policies attached to specific resources (S3 buckets, KMS keys, Lambda functions), bounded organisation-wide by Service Control Policies and per-identity permission boundaries. Microsoft Azure expresses authorisation as role-based access control with Attribute-Based Access Control conditions, scoped through a four-tier hierarchy (management group, subscription, resource group, resource) that inherits downward. Google Cloud binds members to roles on resources, with hierarchical inheritance through the organisation and folder structure, augmented by IAM Conditions and (for data-plane perimeter enforcement) VPC Service Controls. Oracle Cloud Infrastructure expresses authorisation through compartment-scoped policy statements written in a constrained natural-language syntax, where compartments form the principal isolation primitive that inherits permissions downward.

Across providers, three operational habits convert the principle into practice. First, start from zero permissions and add only what is exercised — Access Analyzer (AWS), Permissions Management (Entra), IAM Recommender (GCP), and Cloud Guard policy advisor (OCI) all surface unused privilege so it can be revoked. Second, prefer narrowly-scoped resource-level permissions over wildcards; an s3:GetObject on a named bucket prefix is structurally safer than s3:* on *. Third, separate authoring privilege from runtime privilege; the identity that deploys infrastructure should not be the identity that the deployed application runs as.

Principle 2: Separation of duties

Separation of duties requires that no single identity can author, approve, and execute a privileged change. The threat model is straightforward: a single compromised credential should not be sufficient to push a malicious change to production, exfiltrate data, or disable detective controls. The principle is enforced at two layers — workflow (code review, change approval, deploy gates) and identity (the human who approves the change cannot be the same identity that executes it).

In a cloud context the principle has three concrete implications. Privileged actions — production deploys, IAM policy changes, KMS key policy edits, log destination changes, billing access — pass through a pipeline that records the proposer, the reviewer, and the executor as distinct identities. Break-glass accounts are configured for emergency use only; they are stored offline, rotated after every use, and their use produces a high-priority alert (see general/ir.html for credential-isolation and break-glass patterns). And privileged human identities cannot grant themselves additional privilege without secondary review — Service Control Policies, management-group policy assignments, organisation policy bindings, and tenancy-level admin separation are the four provider mechanisms that close this loop.

A common failure mode is the "super-admin" account that holds both organisational policy authority and day-to-day administrative access. Splitting these into two distinct identities — one for policy authoring (rare use, MFA-only, alerted) and one for routine administration (more frequent, still MFA, less alerted) — closes the largest separation-of-duties gap most cloud tenants exhibit.

Principle 3: Multi-factor authentication

Multi-factor authentication binds an authentication event to possession of a second factor in addition to knowledge of a password. The threat model is the credential-stuffing and phishing class — the attacker holds a valid username and password (sourced from an infostealer log, a credential-stuffing list, or a phishing kit) and attempts to sign in to the cloud control plane. With single-factor authentication this succeeds; with MFA it does not, provided the second factor is phishing-resistant.

NIST SP 800-63B Digital Identity Guidelines define three Authenticator Assurance Levels (AAL1, AAL2, AAL3). AAL2 requires possession of a software or hardware authenticator in addition to a memorised secret; AAL3 additionally requires hardware-based cryptographic proof and verifier impersonation resistance — the property that defeats real-time phishing proxies. FIDO2 / WebAuthn authenticators (security keys, platform authenticators on managed devices) meet AAL3; SMS, voice, and email one-time codes do not meet AAL2 because the channel is bound to a phone number or mailbox rather than a device the user controls. Time-based one-time codes (TOTP) meet AAL2 but do not resist phishing kits that proxy the second factor in real time (the Evilginx-class adversary-in-the-middle pattern); FIDO2 binds the assertion to the legitimate origin and refuses to release credentials to the proxy.

The four major providers all support phishing-resistant MFA, and the operational baseline has tightened over the last two years. AWS began enforcing root-account MFA on AWS Organizations management accounts in 2024 and is extending the enforcement to standalone and member accounts; root accounts without MFA can no longer perform sensitive operations. Google Cloud announced mandatory MFA for all Cloud user accounts, with a phased rollout completing in 2025; the enforcement defaults to 2-Step Verification with FIDO2 security keys (Titan or third-party) recommended. Microsoft Azure has historically driven MFA enrolment through Conditional Access and Security Defaults, and Microsoft has announced mandatory MFA for accessing Azure resources via the portal, CLI, and PowerShell. Oracle Cloud Infrastructure supports MFA per IAM Domain with multiple factor types including FIDO2, mobile authenticator, and time-based OTP. The illustrative control later on this page elaborates the phishing-resistant MFA pattern with full compliance-table markup.

Principle 4: Identity federation

Identity federation centralises authentication in a single identity provider (Microsoft Entra ID, Okta, Ping, Google Workspace, or equivalent) and grants the cloud tenants access via SAML 2.0 or OpenID Connect single sign-on. The alternative — local user accounts per cloud tenant — multiplies the credential surface, splits MFA enforcement across uncoordinated systems, and makes off-boarding a manual checklist across four consoles. A single IdP collapses these into one enrolment, one MFA enforcement, one off-boarding action, and one consolidated sign-in log.

On the human side, the pattern is mature. AWS exposes federation through AWS IAM Identity Center (formerly AWS Single Sign-On), which fronts the four AWS account roles a federated user assumes; Azure relies on Entra ID natively (the Azure tenant is the Entra tenant); GCP integrates Cloud Identity with external IdPs over SAML/OIDC; OCI Identity Domains federate to external IdPs with the same protocols. In all four cases the local cloud user accounts are reserved for break-glass and the occasional IdP-cannot-reach-cloud emergency path; the day-to-day human population lives in the IdP.

On the workload side, federation eliminates static service-account keys — the static credentials that historically leaked to public source repositories, CI logs, and infostealer captures. AWS IAM Roles for Service Accounts (IRSA) and EKS Pod Identity grant Kubernetes pods AWS roles via an OIDC trust between the EKS OIDC provider and IAM; the pod presents a ServiceAccount token, IAM exchanges it for temporary credentials. GCP Workload Identity Federation extends the same pattern to GitHub Actions, GitLab CI, and any OIDC-issuing system. Azure Workload Identity Federation does the same for AKS and external CI; OCI supports workload identity for OKE through Instance Principals and Resource Principals. The design rule across providers: workload credentials should be short-lived, identity-federated, and tied to the workload's runtime context — never long-lived JSON keys stored in a CI variable.

Principle 5: Secrets management

Secrets management is the discipline of keeping credentials, API keys, database passwords, signing keys, and certificate private material out of source repositories, CI logs, container images, environment-variable dumps, and any other forensically loud location. This page is the canonical place this guide treats secrets management; other pages (notably general/workloads.html) link here rather than repeating the material.

The provider secret stores — AWS Secrets Manager and the Parameter Store SecureString tier, Azure Key Vault, Google Cloud Secret Manager, and OCI Vault — share a small set of properties: secrets are encrypted at rest with a customer-controllable key, access is logged through the control-plane audit log, retrieval is granted through IAM rather than through possession of the secret value, and rotation is either built-in (Secrets Manager) or scriptable through provider primitives. The operational pattern is consistent: the application's IAM principal holds permission to retrieve the named secret at runtime; the secret value never crosses into a source repository, a CI log, or a container image layer; rotation is automated and the application reads the latest version on each retrieval or at a configured interval.

Static cloud access keys are the canonical anti-pattern. An AWS IAM user access key, a GCP service-account JSON key, an Azure client-secret string, or an OCI API signing key checked into a source repository or pasted into a CI variable is the credential class that infostealer scans and public-repo crawlers harvest at industrial scale. The Snowflake credential-stuffing incidents of 2024 are the canonical recent example — the credentials in those breaches did not need to be cloud-provider keys to enable mass data exfiltration; any long-lived authentication secret without MFA on the destination account suffices. The remediation is the same in every case: rotate and revoke the static credential, migrate the workload to workload-identity federation (see Principle 4), and add a secret-scanning hook to every commit and CI pipeline.

Principle 6: Privileged access

Privileged access is the practice of granting elevated permission only when it is needed, only for as long as it is needed, and from administrative endpoints whose own hygiene is verified. Standing privileged access — a human user with permanent global-administrator, organisation-administrator, or tenancy-administrator role assignment — is the single largest blast-radius identity in any cloud tenant; the operational discipline is to make standing privilege the exception and just-in-time elevation the default path.

Microsoft Entra Privileged Identity Management is the most mature implementation: users are eligible for privileged roles, and activation requires MFA, optional approval, optional ticket reference, and a bounded duration after which the role assignment is revoked automatically. AWS IAM Identity Center supports session policies that scope an active session below the assumable role's permissions; combined with permission-set duration limits and CloudTrail visibility into role assumption, this approximates just-in-time elevation. Google Cloud's IAM Conditions and the (recently general-availability) Privileged Access Manager provide time-bound role grants. OCI Identity Domains separate administrators by domain and support time-bounded policy statements through dynamic groups.

Privileged administrative actions should additionally originate from administrative endpoints — workstations or jump hosts that are managed, patched, EDR-equipped, and isolated from the day-to-day browsing surface that delivers phishing payloads. The discipline matters because phishing-resistant MFA defeats credential theft but not endpoint takeover; an attacker with code execution on an admin's laptop can ride the existing authenticated session through the proxy.

Cross-provider equivalence

Provider-specific control IDs that implement each principle in this summary are catalogued on the per-provider IAM pages: AWS IAM, Azure IAM, GCP IAM, OCI IAM.

The table below summarises the primary provider primitive that implements each principle. The mapping is deliberately one cell per provider per principle; the provider IAM pages — AWS, Azure, GCP, OCI — extend each entry to the depth a hardening reviewer requires. Where a provider exposes multiple primitives for the same principle (AWS's identity-based vs resource-based policies, for example) the cell names the load-bearing primitive; the others are described inline in §Least privilege above.

Illustrative control — Phishing-resistant MFA

The control entry below is an illustrative example of the canonical control-box markup every Phase 5 provider IAM page mirrors. It is included on this principles page to demonstrate how a principle (Multi-factor authentication, §3 above) translates into a concrete, severity-rated, compliance-mapped control. Provider-specific controls — with CLI remediation, Terraform IaC, and per-provider compliance-row specificity — live in the four provider IAM pages and not here.