Shipping it safely
1. Shipping it safely
Identity, tokens, tenant boundaries, secrets, encryption, evidence. Six threads, and this is where they meet. You're about to ship the tenant report service that has run through this course, and this video is the pass you make over it before you deploy.2. What the checklist is for
A secure-by-default checklist is a fixed set of pre-flight checks: questions you ask before you ship, not after an incident. Notice they are questions. A setting has one right value; a question's answer depends on your service.3. Six questions, in request order
Six questions, in the order a request meets them. One: who verifies the caller's token at API Gateway, before your code trusts it? Two: which identity is AWS checking? A role scoped to the job, never a stored key.4. Six questions, in request order
Three: what stops one tenant reading another's rows in DynamoDB? Tenant isolation means the boundary is carried by the request's identity, not by a filter in your code. Four: where does the database password live, Secrets Manager or your environment?5. Six questions, in request order
Five: who holds the KMS key that protects the reports in S3, and can you show who used it? Six: if someone downloads a report tomorrow, will CloudTrail have a record? Six questions, one service.6. Ticked is not the same as safe
Every one of those has an answer that's switched on and still wrong. An oven at temperature tells you the oven is on, not that the chicken is cooked. Take the identity question: a role instead of a key, reading every object.7. Ticked is not the same as safe
The tenant question: a column, with the filter in your code rather than in the request's identity. The key question: encryption on, and an AWS managed key cannot be shared. Three ticks, three open questions.8. The gap a config cannot show
There is a fourth kind of gap, and no configuration shows it. A policy can be right the day you write it and too broad three months later, because the service stopped calling half of it.9. The gap a config cannot show
Only the log shows that. Granted is not the same as used, so compare the two and cut the difference. That is evidence-driven policy tightening, and it is the loop this course has been building.10. Write the reason, not the setting
Now write it down. The setting is already in your infrastructure code; what's missing is why you chose it. A value with no reason beside it is a magic number, and it gets changed.11. Write the reason, not the setting
Four lines per decision: what you chose, what you rejected, what would change your mind, and the date. A gap written down and accepted is a decision; the same gap undocumented is a surprise.12. The same questions, new callers
The six questions don't stop at your service. Workload identity is the same idea applied to callers that aren't people: a deployment pipeline, a build job, an agent calling AWS for a user.13. The same questions, new callers
Each needs an identity AWS can check, a scope no wider than its job, and a record of what it did. You already know how to answer those. The caller changed; the questions did not.14. Where this goes next
One layer sits above yours. GuardDuty, Security Hub, AWS Config, and Organizations service control policies watch whole accounts, not one service. That is Security Specialty territory. Before your next deploy, ask all six out loud, starting with the one you'd least like to answer.15. Let's practice!
Let's put the pre-launch checks into practice with some exercises.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.