Chapter 10 — Cloud and container security: control configuration
Lesson map
Lesson 10 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Account-level block"]
N2["10.2 Encryption"]
N3["10.3 Versioning"]
N4["10.4 Logging"]
N5["10.5 Change records"]
N6["10.6 Testing"]
N7["Order of changes"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Account-level block"]
N2["10.2 Encryption"]
N3["10.3 Versioning"]
N4["10.4 Logging"]
N5["10.5 Change records"]
N6["10.6 Testing"]
N7["Order of changes"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]
[Learning outcomes]
|
v
[10.1 Account-level block]
|
v
[10.2 Encryption]
|
v
[10.3 Versioning]
|
v
[10.4 Logging]
|
v
[10.5 Change records]
|
v
[10.6 Testing]
|
v
[Order of changes]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) configure storage controls; (2) apply them safely; (3) record changes.
10.1 Account-level block
Providers offer a setting that blocks public access for all buckets in an account. Fairway enables it, with the assets bucket moved to a separate account where public reads are allowed. The account-wide block refuses any policy that grants public access, so the March change would simply have failed. Putting assets in their own account lets the block apply everywhere else without exceptions in the main account. Tomás tests the website's image loading after the move, because a broken website would push staff to ask for the block to be removed.
10.2 Encryption
Default encryption ensures new objects are encrypted at rest. Driver-photos lacked it, which is why verification marked that bucket the most serious. Default encryption applies to new objects only, so existing photos need to be re-written to be encrypted. Tomás plans that copy with the bucket owner in HR and confirms the result with the verification check afterwards. The setting is applied through the configuration repository, like every other change in this work. Encryption keys are managed by the provider's key service, and only the storage service can use them. Tomás records the setting for each bucket so the verification check can confirm it daily rather than relying on memory.
10.3 Versioning
Versioning keeps earlier copies so deleted or overwritten files can be restored. For manifests and driver-photos, which lacked it, versioning protects against accidental overwrites and against a compromised identity deleting files. It does increase storage use, so the lifecycle rule removes old versions after ninety days. Tomás tests a restore from an earlier version in staging before relying on the setting. Versioning is enabled on manifests and driver-photos through the repository and confirmed by the verification check. Backups already had it, which is why that bucket passed. The ninety-day lifecycle rule is reviewed with the storage costs each quarter, so its period can be adjusted if needs change.
10.4 Logging
Access logging records reads and writes for investigation. The March timeline existed only because manifests already had access logging. Extending it to every sensitive bucket, and to site-assets, means any future exposure can be measured rather than guessed at. Logs go to a separate bucket that the identities they record cannot change, so a compromised account cannot erase its own trail. Logging is enabled bucket by bucket through the repository and confirmed by the verification check. Tomás also checks that the log bucket itself is covered by the account-level block. Retention for access logs is set long enough to cover an exposure discovered weeks after it began, which March showed can happen.
10.5 Change records
Each change is made through the configuration repository with review, not in the console. Console changes leave no review and are easy to forget, which is exactly how the March policy change happened. Changes through the configuration repository show who proposed them, who reviewed them and when they were applied. The repository also becomes the declared state that the later drift check compares with what is live. Grace or another team member reviews each change before it is merged. The merge request links to the action from the incident review that the change addresses.
10.6 Testing
Each change is tested on a staging bucket first. Staging lets Tomás see whether a change breaks anything before customers or staff notice. For the account-level block, staging showed the website still loaded images from the new assets account. Not every breakage appears in staging; the marketing tool failure later came from a gap in staging coverage. Each test result is attached to the change record before Grace signs it off. A failed staging test sends the change back for correction rather than letting it go ahead with a note. Tomás later adds the marketing tool to staging, which closes the gap the brochure failure exposed.
Order of changes
Tomás applies changes in an order that reduces risk. First, the account-level public block, because it prevents the incident pattern immediately. Second, removing developer policy permissions. Third, default encryption, then versioning and logging. Each step is small, tested and recorded, so if something breaks, the cause is obvious.
He informs developers before each change through the team channel, explaining what changes and whom to ask if something stops working.
Costs
Versioning and logging add storage cost. Tomás estimates them with Grace: logs and old versions for Fairway's volumes cost a small monthly amount, and a lifecycle rule deletes old versions after ninety days to keep costs predictable.
Recording
Each change record links to the review, the test result and the date applied.
Rollback plan
Each change has a written rollback step, tested in staging, so it can be undone quickly if needed.
Sign-off
Grace signs off each change.
Worked example
Moving the assets bucket to its own account takes a day of testing because the website must keep loading images. Tomás tests the new address in staging before switching.
Synthetic case. Synthetic.
Errors and limits
Account-wide settings can break legitimate uses; plan exceptions before enabling them.
Exercises
- EX037 — Account block. Why move assets to another account? Rubric: 3 = so account-wide block can apply elsewhere; 2 = partial; 1 = vague; 0 = none.
- EX038 — Versioning. What does versioning allow? Rubric: 3 = restoring deleted or overwritten files; 2 = partial; 1 = vague; 0 = none.
- EX039 — Change route. How are changes made? Rubric: 3 = repository with review; 2 = partial; 1 = vague; 0 = none.
- EX040 — Testing. Where were changes tested first? Rubric: 3 = staging bucket; 2 = partial; 1 = vague; 0 = none.
Synthesis
Configure controls through reviewed, tested changes.
Continue studying — chapter 10 of 18
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →