Account Security and IAM
Get this module right before creating anything else. A compromised AWS account can run up a five-figure bill in hours with crypto-mining servers.
Secure the account on day one
- Enable MFA on the root user, then stop using root for daily work.
- Set up IAM Identity Center (SSO) and create a personal admin user for yourself with MFA.
- Create a billing budget with email alerts (for example at $10 and $50).
- Turn on CloudTrail in all regions: a log of every API call in the account.
- Turn on GuardDuty for automated threat detection.
IAM building blocks
| Concept | Meaning |
|---|---|
| User / identity | a person (prefer SSO identities over long-lived IAM users) |
| Role | a set of permissions that people, servers or services assume temporarily |
| Policy | a JSON document listing allowed or denied actions on resources |
A least-privilege policy
The app needs to read and write only its own uploads folder:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
"Resource": "arn:aws:s3:::pandadev-uploads/uploads/*"
}
]
}
Not s3:*, not "Resource": "*". If the app is compromised, the attacker gets this folder and nothing else.
Roles instead of keys
Long-lived access keys are the number-one source of cloud breaches: they end up in Git, in logs or on laptops.
- EC2 servers get permissions through an instance role; the SDK picks them up automatically, no key needed.
- Lambda functions and ECS tasks get execution roles.
- GitHub Actions should use OIDC federation to assume a role and receive credentials valid for an hour.
- If you must use a key (an external platform like Render calling S3), scope it to one bucket, store it only as an env var and rotate it regularly.
Tools to check yourself
- IAM Access Analyzer finds resources shared outside your account and suggests tighter policies based on actual usage.
- The policy simulator tests whether a policy allows an action before you rely on it.
aws sts get-caller-identitytells you which identity your CLI is using right now.
If a key leaks
Deactivate it immediately in IAM, check CloudTrail for what it was used for, delete any resources the attacker created (check every region), then create a replacement. Contact AWS support if there are fraudulent charges.
Check yourself
- What five things should you do on a brand-new account?
- Why are roles safer than access keys?
- What is wrong with
"Action": "s3:*", "Resource": "*"?
I tuoi progressi sono salvati solo in questo browser.
Invia per la revisione (10 punti)