home / home-lab / cloud identity range
Cloud Identity Range
A disposable cloud identity lab with a landing-zone baseline, immutable logs and a set of IAM privilege paths, each paired with the detection that would catch it.
Objective
Most real-world cloud incidents are identity incidents. A leaked key, an over-broad role or a consented OAuth application is enough to move from “a person clicked something” to “the data left”. The range exists so I can build those paths deliberately, watch what the audit trail records, and test whether a detection rule actually fires.
It is the cloud counterpart to the isolated research range: the same idea of a disposable, default-deny environment, applied to identity and access management instead of a network of virtual machines.
Architecture
trust zones, flows and logging pointsLegend
- A control identity: a pipeline identity that applies the baseline. No long-lived human credentials, and it cannot grant itself more access.
- B organisation: holds the guardrails: organisation policy, a budget kill-switch and central log routing.
- C sandbox project: throwaway principals and resources. No real data and no path to production.
- D audit log sink: append-only, in a separate project, so a compromised principal cannot rewrite its own trail.
- E break-glass: a sealed, rarely used account that raises an alert the moment it is touched.
Trust zones
| Zone | Trust | May reach | Logged |
|---|---|---|---|
| A control identity | Trusted, minimal | B (deploy baseline only) | CI run log, control-plane audit |
| B organisation | Trusted | A, C, D | Organisation audit log |
| C sandbox project | Untrusted | B guardrails, D write-only | CloudTrail / audit logs per call |
| D audit log sink | Trusted | Receives from B and C | Access and retention log |
| E break-glass | Sealed | B, then re-sealed | Alert on any authentication |
Landing-zone guardrails
The baseline is applied as code, so the range can be rebuilt exactly and the guardrails are not something I have to remember to set by hand.
- Organisation policy denies paying for extra services, creating users with console passwords outside the sandbox, and disabling audit logging.
- A budget with a kill-switch, so a runaway scenario cannot turn into a bill.
- All control-plane logs shipped to the sink in a separate project; the sandbox cannot delete or edit them.
- Default service accounts are disabled; permissions are granted per scenario and removed when it ends.
- Break-glass credentials are sealed offline and generate a high-severity alert on first use.
# organisation policy (excerpt): deny the easy ways out\n{ "Version": "2012-10-17", "Statement": [\n { "Sid": "DenyLogTamper", "Effect": "Deny",\n "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "logs:DeleteLogGroup"],\n "Resource": "*" } ]}Monitoring
Every scenario is run with the audit trail already flowing to the sink, so what the range records is the raw material for the detection rules. The cloud rule published alongside this lab watches IAM for the exact behaviours the scenarios produce.
- Control-plane audit logs per API call: principal, source, request parameters, result.
- Identity events: key creation, policy attachment, group membership and MFA changes.
- The same events routed to a query engine so a rule can be tested against a real run before it is published.
Scenarios
what I run and what it proves01 · A long-lived key that outlives its purpose
Run: create an access key for a principal, use it, and leave it active. Detected: key creation and use from an unexpected source, mapped to T1098.001. Changed: scenario rewritten to use short-lived federation so the noise-prone rule is not defeated by habit.
02 · Permissions that grow one policy at a time
Run: attach inline policies and add the principal to a group until it can read a data store. Detected: policy attachment and group membership changes, mapped to T1098.003. Changed: a rule that alerts on the aggregate, not only the single call.
03 · Turning MFA off
Run: deactivate MFA for an account, then authenticate with only a password. Detected: the MFA change event, mapped to T1556.006. Changed: MFA changes joined the small set of events that page rather than queue.
04 · The consented application
Run: grant an OAuth application broad delegated access, then read resources as that application. Detected: the consent grant and the subsequent reads from a new user-agent and address. Changed: what I look for in the consent-phishing case study.
Keeping the range safe
- No real data, no production access, no client identity in any scenario.
- The sandbox is torn down and rebuilt from code after each run; nothing persists by accident.
- Guardrails are deny-by-default and deny disabling the audit trail.
- Results and logs are reviewed before anything leaves, under the sanitization policy: identifiers and account IDs are replaced with placeholders.
Limitations
- A sandbox project is not a production organisation: scale, legacy permissions and human process are missing.
- Detections based on provider audit logs see the control plane; data-plane and application-level abuse need their own logging.
- A scenario that depends on a misconfiguration I introduced proves what a rule catches, not how common that misconfiguration is.
Tags
#lab#cloud#iam#detection#identity