Cloud Identity & Data Exposure

Identity and Access Management (IAM) is the true perimeter of the cloud. There are no cables to unplug; access is decided entirely by policy. In AWS terms, identities (users, groups, and — crucially — roles) are granted permissions by policies, JSON documents that allow or deny specific actions on specific resources under optional conditions.

A role is the cloud-native ideal: an identity with permissions but no long-term password or keys. Workloads and users assume a role and receive short-lived credentials for it. This is far safer than sprinkling permanent access keys across servers and laptops.

The evaluation logic is worth memorizing because it drives real design. In AWS, access is denied by default; an Allow is needed to permit an action; and an explicit Deny anywhere always wins over any Allow. Policies attach at multiple layers (identity policies, resource policies, permission boundaries, Organization SCPs), and the effective permission is their intersection minus any explicit deny.

Modern cloud auth runs on temporary credentials. AWS's Security Token Service (STS) mints short-lived credential sets — an access key, a secret, and a session token — that expire in minutes to hours. Assume a role, get a token, use it, let it expire. Because the credential is ephemeral, a stolen one has a limited useful life.

But "limited" is not "zero," and token theft is now a central attack technique. If an attacker can grab a valid session token — from a compromised host, a leaked environment variable, a poisoned CI/CD pipeline, or a metadata-service attack (next section) — they can act as that identity until the token expires, without ever knowing a password or triggering MFA. MFA protects the initial login; it does not re-challenge every API call the resulting token makes.

This is why session duration and scope are security parameters, not conveniences.

Cloud VMs need credentials to call other services, so providers expose them through the Instance Metadata Service (IMDS) — a magic link-local address, 169.254.169.254, reachable only from the instance itself. Query it and you get instance details and, critically, the temporary credentials of the role attached to that instance.

That is enormously convenient and enormously dangerous, because it turns any Server-Side Request Forgery (SSRF) bug into a credential heist. In SSRF, an attacker tricks a server into making a request to a URL the attacker controls. If they can point that server at http://169.254.169.254/..., the server helpfully fetches its own role credentials and hands them back.

This is the mechanism behind the 2019 Capital One breach. An attacker exploited an SSRF flaw in a misconfigured web application firewall running on EC2, reached the IMDS, retrieved the instance role's temporary credentials, and used them to list and copy S3 buckets — exposing data on roughly 100 million people in the US and about 6 million in Canada.

The fix is IMDSv2: a session-oriented scheme that requires a preliminary PUT to obtain a token, sets a low network hop limit, and thereby blocks the naive SSRF-fetches-metadata pattern. Enforcing IMDSv2 (and disabling v1) is now a baseline hardening step.

Cloud object storage — Amazon S3, Azure Blob Storage, Google Cloud Storage — is where the world keeps its data, and where a staggering amount of it leaks. The buckets are private by default, but a stream of accidental public exposures has made "open S3 bucket" almost synonymous with data breach.

Exposure comes from several directions:

• Overly permissive access policies or ACLs granting read (or worse, write) to the public or to "any authenticated AWS user."
• Compromised credentials used to read the bucket via the API, as in Capital One.
• Public static-hosting settings turned on for convenience and forgotten.

The defenses are concrete and layered: enable account-wide Block Public Access (S3) or equivalent, require encryption at rest and in transit, use bucket policies with explicit conditions, enable object versioning and access logging, and scope read access to specific roles rather than the world.

Two final exposures round out the identity-and-data picture. First, network telemetry: VPC flow logs record metadata about traffic to and from your network interfaces — source, destination, port, bytes, accept/reject. They do not capture packet contents, but they are invaluable for spotting exfiltration, lateral movement, and traffic to suspicious IPs, and they feed detection services like GuardDuty. Turn them on for sensitive subnets.

Second, and pervasively, secret leakage. Long-lived access keys, API tokens, and private keys end up hardcoded in source, committed to Git, baked into container images, pasted in tickets, and dropped in logs. Automated bots scan public GitHub continuously and will find and abuse an exposed AWS key within minutes — often to spin up expensive compute for crypto-mining.

The durable answer is to stop having long-lived secrets at all: use roles and short-lived tokens, store any unavoidable secrets in a managed vault (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault), inject them at runtime, and run automated secret-scanning in your pipelines to catch leaks before they ship.