The previous lesson ended by pointing at the bridge: immutable infrastructure and containers are the best way to apply a baseline, and yet classic hardening does not cover them. A container is not a virtual machine, it is not patched but rebuilt, and the cloud account that runs it has a surface of its own that no lynis looks at. This lesson closes the course's technical plan where most breaches happen today: not through a sophisticated exploit, but through a wrongly ticked box. We are going to configure, once and for all, account A-05, the attachments bucket A-02 and the backups A-03, and to build images that do not give the game away.

1. Why the cloud changes the threat model
2. Shared responsibility, on the technical side
3. Identity is the new perimeter
4. Bucket A-02, properly configured at last
5. Network and data: private subnets, encryption and isolated backups
6. Cloud logging and auditing
7. Automated posture: CSPM and infrastructure as code
8. Containers: what they isolate and what they do not
9. Secure execution and image signing
10. Orchestration and runtime detection
11. What Nimbus should do first, on its budget

In your own data centre, attacking meant finding a vulnerable service and exploiting it. In the cloud, the dominant cause of breaches is not an exploit: it is a configuration error. The big public incidents of the last decade in cloud environments share a pattern that requires no offensive skill at all: a bucket marked as public, an access key published in a repository, a role with administrator permissions that only needed to read one file, a managed database exposed without authentication.

Three underlying changes explain the shift:

• Everything is an API. Creating a machine, opening a port or granting access to all the data are API calls, and a credential with broad permissions lets you make all of them. The control plane matters more than the data plane: whoever controls the account does not need to log into any server.
• Speed is both the advantage and the risk. A terraform apply stands up a complete infrastructure in minutes, and it also publishes a bucket in seconds. The same agility that makes Nimbus competitive multiplies the probability of error.
• Everything is public by default in terms of network reach. There is no physical door and no corporate network around it: whatever is deployed is reachable from the Internet unless you configure otherwise.

The practical consequence inverts the order of work: in the cloud, reviewing the configuration pays off more than hunting for vulnerabilities, and that is why the CSPM in section 7 is, for an SME, more cost-effective than an additional vulnerability scanner.

In 04-04 we saw the model as a contractual matter. Here it is a list of concrete tasks, and the question that orders it is: if this fails, who do you call? If the answer is you, it is yours.

Two conclusions worth keeping in mind. The first: the more managed the service, the fewer tasks you have, but the ones that remain are the most critical — the access configuration and the data. The second: the provider does not warn you when you get it wrong. Publishing a bucket generates no alert on their side: the checkbox exists, and using it is a legitimate customer decision. That asymmetry is exactly the gap where the configuration error lives.

With no network to defend, access control to the provider's API is the real perimeter. Five rules, ordered by impact:

1. Mandatory MFA on the root account, with the credential held in custody and not used day to day. Root is only used for what no other identity can do.
2. No long-lived access keys. A static key lives in a file, travels through chats, gets copied to a laptop and turns up in a repository: it is risk R-06. Instead, assumable roles with short-lived credentials (minutes or hours) for people, and the instance's or the container's own identity for services, with no secret to manage at all.
3. Federation with the identity provider. Nobody has their own user in the cloud: you log in with the corporate identity, and offboarding an employee revokes their access to everything at once. It is the fix for a classic problem: the cloud account that outlives the person who used it.
4. Real least privilege, achieved by observing what each role actually uses and trimming the rest.
5. Periodic review of excessive permissions, with the provider's access analyser and with the six-monthly recertification of control C-18.

Three decisions deserve justifying. s3:DeleteObject is not granted: the Nimbus API never needs to delete attachments, and not having it turns a compromise of the API into a leak — serious — instead of a destruction — irreversible. The Resource bounds the path, not just the bucket, so an application flaw cannot reach other prefixes. And the explicit deny by VPC endpoint is the most powerful: even if another policy grants access by mistake, if the request does not come over Nimbus's private network, it is denied. A stolen credential used from outside is useless.

This is the asset that 02-06 emptied over seven days. It is closed with seven controls applied together.

The two remaining controls apply to the backups bucket A-03, and they are the ones 02-06 proved indispensable:

COMPLIANCE mode is the difference between a backup and a hope. In governance mode, an administrator can lift the retention; in compliance mode, nobody can, not even the account owner, until it expires. It is the fourth digit of the 3-2-1-1-0 rule from 04-06 and it is, literally, what would have prevented the deletion on day 20 at 02:10.

And the seventh control, already familiar: downloads are served with 120-second signed URLs (03-07), generated after the authorisation has been checked in the application (05-05). There is never a permanent link and never an object readable without a credential.

Picking up the design from 05-04 with managed services in mind:

• The database lives in a private subnet with no route to the Internet, inbound or outbound. It is not "a closed port": there is simply no path.
• Private endpoints (VPC endpoints) for talking to object storage and to the secrets manager. The traffic does not go out to the Internet and — most valuably — it enables the aws:SourceVpce condition from section 3, which cancels out the value of a stolen credential.
• Encryption at rest and in transit by default across every service, with Nimbus-managed keys and rotation using kid (03-06). The provider's encryption protects against physical theft of the disk; encryption with your own key also protects against logical access mistakes.
• Blocking the metadata service, or requiring its session-based version (IMDSv2), which is the structural mitigation for the SSRF from 05-05: without it, an SSRF in the API hands over the instance role's credentials.
• The backups live in another account, with different credentials. It is the most expensive lesson of 02-06: Nimbus's backups were in the same account as production, and whoever compromised the account deleted them along with everything else. Backups in another account mean the attacker has to compromise two independent accounts, with two sets of credentials and two identity providers. The added cost is a few euros a month.

The provider's activity log (CloudTrail or equivalent) answers who called which API, when, from where and with what result. It is the most important source in a cloud environment and it has to be configured properly:

• Enabled in every region, not just the one you use. A common technique is to operate in a region nobody looks at.
• Shipped to a bucket in another account, with the same properties as in section 4: immutable and write-only. Logs are protected in the same way as backups.
• Integrity validation enabled, so that you can prove they were not tampered with.
• Complemented with the bucket access logs, the load balancer's and the VPC flow logs (05-04).

The minimum alerts, which connect directly with the catalogue from 05-02:

The first five are S1 because none of them has a frequent benign explanation. They are also dirt cheap to set up: they are queries over a log that already exists.

CSPM (Cloud Security Posture Management) is continuously evaluating the account's configuration against a set of best practices. prowler and ScoutSuite are free and good enough.

A commented reading, using the prioritisation criterion from 05-01. iam_root_mfa_enabled comes first, despite not being the noisiest: without MFA on root, every other control is optional for whoever gets hold of that credential, and enabling it takes five minutes. The public bucket comes immediately afterwards, and the first question is not how to close it but what it contains and since when it has been like that: if it holds personal data, this is no longer a configuration finding, it is a possible breach (04-05, 06-03). The access key unused for 402 days is the quietest finding and one of the most dangerous: a permanent, forgotten credential that nobody would miss if somebody used it; it is deleted, not rotated. And the disabled backups in preproduction point once more at A-22.

Shifting the control left. CSPM catches the error after it reaches production. checkov and tfsec catch it in the pull request, in the infrastructure code, before it exists:

The correct combination is checkov blocking in CI and prowler weekly against the account, because not everything is deployed as code: there is always something done by hand in the web console, and only CSPM sees that.

The sentence to internalise: a container is process isolation, not a security boundary like a virtual machine's. If you need to separate workloads of very different trust levels, the correct boundary is the virtual machine or a separate account.

The last comment deserves emphasis because it is the most common mistake and the least obvious: deleting a file in a later layer does not remove it from the image. It is still in the earlier layer and can be recovered with one command. That is why trivy --scanners secret (05-01) is part of the pipeline.

Building the image well is half of it; the other half is how it is run.

read_only plus cap_drop: ALL plus no-new-privileges is the combination that raises the cost of an attack the most, and it costs nothing: most web applications work exactly as they are, and the ones that do not just need to declare their write paths as volumes.

Artefact signing with cosign (picking up 03-07), which answers the question "is this image the one we built?":

Without verification at deployment time, the signature is decorative. The complete chain looks like this, and it is the supply chain integrity from 04-04 put into practice:

Nimbus does not use Kubernetes yet, and it is worth saying clearly that Kubernetes is a security domain in its own right, not a deployment detail. If it arrives, these are the six minimum pieces: namespaces per environment and per criticality, with quotas; RBAC with dedicated service accounts per application and no use of the default account; network policies, because by default every pod talks to every other pod — this is the most frequent mistake and the equivalent of the flat network in 05-04; pod security standards at the restricted level, which enforces what section 9 describes; secrets management with an external provider, because native secrets are base64-encoded and not encrypted; and kube-bench, which evaluates the cluster against the CIS benchmark just as lynis evaluates a server.

Runtime detection with Falco. Image scanning looks at what is there; Falco looks at what happens, by observing system calls:

What is worth detecting at runtime, without generating noise: a shell inside a container, writes to system paths (/etc, /usr/bin) when the filesystem should be read-only, an outbound connection to an unexpected destination, reads of sensitive files such as /etc/shadow or the instance credentials, and the Docker socket being mounted. They all go to the same channel from 05-02 and share its alert quality rules.

The total comes to around 540 €/year and about 70 hours. That is less than 3 % of the 18,000 €/year budget and 16 % of Lucía's 440 hours, and it covers the three highest-scoring risks in the register from 04-01. It is, by a distance, the best cost/impact ratio in the whole of module 5, and the reason is the same one the lesson opened with: in the cloud, almost everything that fails is a checkbox, and checkboxes are free.

• Believing the provider protects you from your own configurations. It does not warn you when you publish a bucket: that is a legitimate customer action.
• Using long-lived access keys. They end up in a repository, in a chat or on a laptop. Short-lived roles and instance identity.
• Granting Action: "*" "temporarily". Nothing is more permanent than a temporary permission that works.
• Leaving the backups in the same account as production. That is what turned the incident in 02-06 into a catastrophe.
• Trusting that a container isolates like a virtual machine. It shares the kernel; with extra capabilities or the Docker socket mounted, it is the whole host.
• Tags instead of digests. :latest is not reproducible: you scan one image and deploy another.
• Secrets in the Dockerfile's ENV. They stay in the layer even if you delete them later.
• Tip: start with the first two rows of the table in §11. Four hours, zero cost, and they cover the worst possible scenario.
• Tip: verify, do not configure. A curl returning 403 is worth more than a screenshot of the web console, and it is the evidence 04-03 asks for.
• Tip: checkov in CI before prowler on the account. It is cheaper to prevent the error than to discover it, although you will need both.

Working from the prowler output in §7, and knowing that nimbus-web-assets serves the public images of the marketing website:

1. Rank the six findings by real priority, justifying each position.
2. Does your assessment of the public bucket change once you know what it is used for? What would you check before deciding?
3. Write the specific fix for the first three and state how you would verify each one.

Iván proposes this service for production. Identify every problem and rewrite it.

After reading the post-mortem of 02-06, Marta asks: "how do we guarantee this cannot happen again?". Design Nimbus's backup scheme so that an attacker with total control of the production account cannot destroy them, and state how you would prove it.

Exercise 1

(1) Ranking by real priority:

(2) Yes, it changes, but less than it seems. A marketing image bucket being publicly readable may be exactly what is intended, and in that case the finding is a false positive documented as an exception (04-02). Before deciding you have to check four things: what objects it actually contains — "web assets" buckets very frequently accumulate exports, one-off backups and customer PDFs somebody left there; whether, as well as public read, it has public write, which would be critical because it would let anyone alter the content served under Nimbus's domain; since when it has been like this and what the access logs say; and whether there is a better way of achieving the same thing, which there is: a CDN in front with the bucket private, which gives you control, caching and logging without direct exposure. The general rule: a public bucket is acceptable only if it is a dedicated bucket whose contents are entirely intended to be public and it is recorded as such in writing.

(3) Fixes and verification:

• Root without MFA: enable MFA with a hardware key, keep the credential and the backup second factor in physical custody with two people having access, and create an S1 alert on any use of root (§6). Verification: prowler re-runs iam_root_mfa_enabled with a PASS result, and a test login asks for the second factor.
• Public bucket: if the content has to be public, move it to a dedicated bucket behind a CDN and leave the original private; if not, apply the public access block from §4. In both cases, inventory the contents first. Verification: a curl against a known object returning 403, and put-public-access-block confirmed.
• Unused key: delete it, do not disable it — a disabled key gets re-enabled; first check in the activity log that no process used it in 402 days, and look for it in the repository history with gitleaks (05-01), because a forgotten key is usually forgotten because it was embedded somewhere. Verification: the key no longer appears in the listing and there are no new authentication errors within 48 hours.

Exercise 2

Problems, from most to least serious:

Exercise 3

The requirement restated: destroying the backups must require credentials the production account does not hold and an action no credential can perform. Four layers, each solving a different failure:

1. A separate account, with its own identity provider and its own MFA. Compromising production gives no access whatsoever to the backup account. It is the layer that was missing in 02-06, where everything lived together.
2. A one-way, least-privilege write flow. Production's nimbus-backup role has only PutObject on the backups bucket: it cannot list, it cannot read and it cannot delete. That it cannot read is important and often overlooked: it stops an attacker in production also walking off with the complete history.
3. Object lock in COMPLIANCE mode with 35 days of retention. Here is the core of the answer for Marta: not even an administrator of the backup account with MFA can shorten the retention or delete an object before it expires. It is not a question of permissions, which can always be changed; it is a property of the storage.
4. Replication to a second region and, for the critical set, an additional copy in cold storage with credentials different from all of the above.

It is complemented with detection: alert D-10 from 05-02 on any attempted deletion or retention change, and the silence alert — if the backup process stops writing for 24 hours, somebody must find out — because the stealthy way to destroy backups is not to delete them, but to prevent them being created and wait for the history to expire.

How it is proved, which is what Marta should demand instead of an explanation: (a) a real deletion attempt from the backup account with administrator credentials, which must fail with AccessDenied, with the output kept as evidence; (b) a timed restore test from 04-06, run from the backup account, verifying the hash, comparing rows and measuring the real RTO; (c) a compromise drill: revoke every production credential and check that the backups are still reachable and restorable; and (d) a quarterly review that object lock is still enabled, included in the infrastructure-as-code --check --diff (05-06). The right answer to Marta's question is not "we have configured this": it is "we tried to destroy them and we could not, and here is the dated console output".

You have closed the course's technical plan at the point where most companies break today. You know why the cloud changes the threat model — the configuration error replaces the exploit as the dominant cause — and the three underlying reasons: everything is an API, speed multiplies error and reach is public by default. Hence the inversion of priorities: reviewing the configuration pays off more than hunting for vulnerabilities. You apply the shared responsibility model service by service with the question that orders it — "if this fails, who do you call?" — and with the two conclusions that matter: the more managed the service, the fewer tasks and the more critical they are; and the provider never warns you when you get it wrong.

You have a command of identity as the new perimeter: MFA on root, an end to long-lived keys, assumable roles with short-lived credentials, federation with the identity provider and a review of excessive permissions; with the minimal policy that does not grant Delete, bounds the prefix and adds an explicit deny by VPC endpoint that cancels out the value of a stolen credential. You have configured bucket A-02 once and for all: public access block, encryption with your own key, versioning, access logging and verification with a curl that must return 403; and the A-03 backups in a separate account with object lock in COMPLIANCE mode, which is what turns "immutable" into something real and what would have prevented the deletion on day 20. You know how to set up private subnets, private endpoints, encryption by default, blocking of the metadata service as a structural mitigation for SSRF, and backups that require compromising two independent accounts.

You know how to configure the activity log multi-region, immutable, in another account and with integrity validation, and the seven minimum alerts, five of which are S1 because none has a benign explanation. You can handle CSPM with prowler — reading its report with the criterion from 05-01, starting with root MFA and asking what the public bucket contains before closing it — and blocking checkov in CI so the error never reaches production, with the conclusion that you need both. You understand what a container isolates and what it does not, and you have the Dockerfile before and after: multi-stage, distroless, pinned by digest, --require-hashes, no secrets in layers and no root; with the warning that deleting a file in a later layer does not remove it from the image. You run with read_only, cap_drop: ALL, no-new-privileges and limits, you sign with cosign and you verify before deploying, because without verification the signature is decorative. And you know how to frame Kubernetes as a domain of its own and Falco for detecting what happens at runtime. All of it prioritised in a table that comes to around 540 € and 70 hours and covers the three highest-scoring risks in the register: in the cloud, almost everything that fails is a checkbox, and checkboxes are free.

With that, Module 5 is complete. Nimbus now knows how to find what it has exposed and prioritise it (05-01), see the attacker move with twelve detections that would have cut the incident in 02-06 short on day 0 (05-02), test itself with an authorised pentest and get value from its report (05-03), segment its network and verify that the segmentation really works (05-04), defend its own code with centralised authorisation and a CI that says no (05-05), harden its systems with an automated baseline verified every week (05-06) and close down its cloud and its containers (05-07). One by one, every finding we had been carrying since 01-04 has fallen: the exposed PostgreSQL, the Redis with no authentication, the open SSH, the python -m http.server and the consultancy's permanent access.

And here is the limit of everything above. None of this maintains itself. Tools find and fix, but the monthly scan stops running when Lucía has a bad week; the baseline degrades if nobody looks at the --check --diff; the CSP fills up with exceptions; the security.txt expires; and the next employee to join will know nothing of any of this unless somebody teaches them. What is more, having done the work is not enough: you have to be able to prove it — to a customer demanding guarantees, to an audit, to the AEPD (the Spanish Data Protection Agency) if a breach ever has to be notified. In Module 6: Best Practices and Regulations we move from execution to what sustains it over time: best practices that turn one-off decisions into habits (06-01), regulations and standards such as ISO 27001, NIS2 and the ENS (06-02), data protection and the GDPR genuinely applied to a SaaS handling health data (06-03), compliance and auditing with the evidence this module has been generating (06-04), training and awareness, because people are still the main vector (06-05), and the ethics and responsible disclosure left pending by 05-03 (06-06). We stop asking whether it is protected and start asking whether it can be proved and whether it will last.