Security Engineering / Fundamentals / Cloud
Fundamental 05

Cloud
fundamentals The mental shift: there is no perimeter, no cabling and no console room. There is an API, and whoever holds credentials to it owns your infrastructure. Everything below follows from that one fact.

provider-agnosticread before AWS
Tier 0 · Groundmodels

Who is responsible for what

Module 0.1

Shared responsibility, made specific

The diagram everyone shows and nobody applies
LayerIaaS (EC2)PaaS (RDS, Lambda)SaaS (Workspace)
Physical & hypervisorProviderProviderProvider
OS & patchingYouProviderProvider
Runtime / app codeYouYouProvider
ConfigurationYouYouYou
Identity & accessYouYouYou
Data & classificationYouYouYou

Notice the bottom three rows never move. Configuration, identity and data are always yours — and they are the cause of the overwhelming majority of cloud breaches. "The cloud is secure" and "your cloud is secure" are unrelated statements.

TPRM tie-in: this table is also the shape of a vendor responsibility matrix. When a SaaS provider hands you their SOC 2, the complementary user entity controls are precisely the rows above that stayed with you.
Module 0.2

Control plane vs data plane

The single most useful distinction in cloud security
CONTROL PLANE DATA PLANE "create this bucket" "read object customers.csv" "attach this role" "SELECT * FROM accounts" "open port 22" "SSH into the host" logged in: CloudTrail logged in: S3 access logs / DB audit logs (usually OFF by default)

An attacker with control-plane access rarely needs to break anything: they grant themselves data-plane access legitimately. Conversely, control-plane logs alone will not tell you which records were read — that is why data-plane logging must be deliberately enabled on sensitive stores.

Module 0.3

Identity is the perimeter

Principals, roles, and the credential lifetime problem
  • Human identities should federate from your IdP with MFA — no standing cloud console users, no long-lived access keys.
  • Workload identities should assume roles that issue short-lived credentials (instance profiles, IRSA/workload identity, OIDC federation from CI).
  • Long-lived static keys are the single most common cloud-breach root cause: committed to Git, left in a CI variable, embedded in an app. If you must have them, rotate and monitor for use from unexpected sources.
  • Privilege escalation paths matter more than raw permission counts. The ability to pass a role, edit a policy, create an access key for another principal, or update a Lambda's code are all "become someone more powerful" primitives.
Tier 1 · Mechanicsvisibility

Cloud telemetry and posture

Module 1.1

The four log families

And which questions each answers
FamilyAWSAnswers
Control plane auditCloudTrailWho called which API, from where, when
Network flowVPC Flow LogsWhat talked to what, how much
Data accessS3 access logs, CloudTrail data eventsWhich objects/records were touched
Service & appCloudWatch, ALB logsErrors, requests, application behaviour

Design decisions that always come up: aggregate to a separate logging account with restricted access; make the log bucket immutable (object lock) so an attacker cannot erase their tracks; and be deliberate about data-event volume, which can cost more than the workload it monitors.

Module 1.2

CSPM, CWPP, CIEM, CNAPP

Four acronyms, one product category
  • CSPM — posture: is anything misconfigured? Public buckets, open security groups, unencrypted volumes, missing logging. Usually evaluated against CIS Benchmarks and provider best practice.
  • CWPP — workload protection: vulnerabilities and runtime behaviour inside VMs/containers.
  • CIEM — entitlements: who can do what, including transitive paths nobody intended.
  • CNAPP — the bundle of all three, which is what modern platforms sell.

The value of a good CNAPP is not the finding list — it is attack-path analysis: "this internet-facing container has a critical CVE, runs as root, and its role can read the customer data bucket." One such chain outranks a thousand medium findings, and that prioritisation is what you should judge the tool on.

Agentless scanning caveat: snapshot-based scanning is excellent for coverage and vulnerability inventory, but it is periodic. It will not catch a runtime intrusion between scans. Pair posture with runtime detection and cloud audit logs in the SIEM.
Module 1.3

SaaS risk is a different animal

Where CASB, SSPM and app governance come in

With IaaS you configure infrastructure. With SaaS you configure someone else's product and inherit their defaults. The recurring risks:

  • Sharing and external collaboration defaults — link sharing set to "anyone with the link".
  • OAuth app grants — a user authorises a third-party app to read all their mail and files. No network control sees this; only the SaaS tenant's own logs and app governance do.
  • Admin sprawl — super-admin counts that grow and never shrink.
  • Shadow tenants — teams signing up for the same SaaS on a personal card.
  • Data residency and sub-processors — where the data actually lives and who else touches it.

SSPM (SaaS Security Posture Management) is CSPM for SaaS tenants; Netskope's API-mode CASB overlaps heavily with it, as does Workspace's own security centre. Decide which is authoritative rather than running both blindly.

Drill 1

CloudTrail shows a role assumed from an unfamiliar IP, then GetObject calls are suspected on a sensitive bucket — but you cannot see them. Why?

Data events are opt-in. CloudTrail records management (control-plane) events by default; object-level reads and writes require data-event logging or S3 server access logs to be explicitly enabled, usually per-bucket for cost reasons. This is the classic incident-response gap — decide in advance which buckets are sensitive enough to warrant it, rather than discovering the gap mid-incident.
Tier 2 · Engineerdesign

Guardrails over gates

Module 2.1

Preventive, detective, responsive

Where to spend effort
  • Preventive — organisation-level policies that make a bad state impossible: deny disabling logging, deny public bucket ACLs, restrict regions, require encryption. Cheapest control per unit of risk, because it never generates an alert.
  • Detective — posture scanning plus SIEM rules on audit logs for the things you cannot prevent.
  • Responsive — automated remediation for a small, well-understood set (quarantine a public bucket, revoke a leaked key), manual for everything else.
  • Shift-left — infrastructure-as-code scanning in CI so misconfiguration is caught before it exists in an account. This is where posture debt stops accumulating.

A useful maturity question: for each of your top ten cloud risks, is the control preventive or detective? A programme that is all detective is a programme that will always be reacting.

Referencesearchable

Glossary